コード

コードは、コーディングエージェントに頼むのと同じように、Status200 AI にリポジトリでの作業を頼む場所です。バグの修正、テストの作成、コードの説明、変更の実施などを頼めます。コードを開くと、依頼を書く欄が表示され、その中でリポジトリとブランチを選び、下にすべてのタスクが並びます。タスクのページは返信できる会話です。Status200 も、例外、トレース、調査から自動でタスクを開始します。Runner がリポジトリをクローンし、新しいブランチに変更を書き、ビルドとテストを行って、プルリクエストを作成します。どのプルリクエストも人がレビューしてマージします。Runner にできるのはブランチのプッシュとプルリクエストの作成だけです。

リポジトリで AI に頼む#

1. コードを開く#

   製品 → コード を開きます。AI に何をしてもらいますか？ という見出しの下に依頼を書く欄があり、その下にすべてのタスクが新しい順に並びます。リポジトリがまだない場合は、代わりに GitHub を接続 が表示されます(始める前に を参照)。サイドメニューの リポジトリ には AI が作業できるリポジトリが一覧表示され、GitHub App がもう届かないリポジトリは 未接続 の下にまとめられます。各リポジトリのページにも、そのリポジトリ用の同じ欄があります。

2. リポジトリとブランチを選ぶ#

   欄は、最後に選んだリポジトリで始まります。欄の下の行で別のリポジトリを選び、その横でタスクの起点となるブランチを選びます。別のブランチを選ぶまでは、デフォルト と表示されたリポジトリのメインブランチです。AI は選んだブランチから自分のブランチを作り、そのブランチに向けてプルリクエストを作成します。

3. やりたいことを書く#

   変更、バグ、質問を自分の言葉で書きます。まだ何も依頼していない間は、依頼の例 にいくつかの例が表示されます。

4. コンテキストを追加する#

   コンテキストを追加 をクリックして、AI に必要なものを渡します。リポジトリのファイルやフォルダー、メモ、リンク、プロジェクトのレコードを追加できます。Status200 は依頼を送信した時点で、あなたの権限で各レコードを読み取り、AI に渡した内容を保存します。

5. タスクを開始する#

   タスクを開始 をクリックするか、Enter キーを押します。タスクのページが開き、AI の作業がその場で表示されます。

1 つの依頼に追加できるコンテキストは最大 10 個です。Status200 が読み取った内容に含まれるトークン、キー、パスワード、メールアドレスは、Status200 AI がデータを読むほかの場所と同じく、AI に渡す前に伏せられます。

タスクの会話#

タスクのページは会話です。依頼の内容と追加されたコンテキストの後に、AI のターンが続きます。AI が進めるステップ(読んだファイルと編集したファイル、検索した内容、実行したコマンド)がその場で表示され、続いて AI の返信、変更したファイルとその diff、プルリクエストが表示されます。ページの上部には、タスクの作業場所(リポジトリと開始元のブランチ)、変更した行数、プルリクエストへのボタン、タスクの状況が表示されます。

続けるには、会話をスクロールしても表示されたままの下の欄に書きます。AI の質問に答えたり、コンテキストを追加したり、変更を頼んだりできます。返信はそれぞれ同じタスクの次のターンになり、プルリクエストが開いている間は同じブランチで作業して同じプルリクエストにプッシュします。タスクは一度に 1 ターンずつ進むので、AI の作業中は欄が待機します。各ターンの ログ は、そのターンで行ったことをそのまま記録したものです。

リポジトリを読める人は、そのタスクも読めます。AI への依頼、返信、タスクの停止にはリポジトリを編集する権限が必要で、変更の diff を見る場合も同じです。それ以外の人には、どのファイルが変わったかだけが表示されます。Status200 が自動で開始するタスク(下記)もそのリポジトリに入っており、返信できる会話になっています。

修正の実行の流れ#

1. コードで タスクを開始 をクリックするか、未解決の例外で AI で修正 をクリックするか、別のボタンやトリガーがタスクを開始します(修正タスクの開始場所 を参照)。
2. タスクはそのリポジトリのキューに入り、リポジトリが選んだ Runner がそれを取得します。自社の Runner のいずれか、または何も選んでいない場合はグローバル Runner です(リポジトリの Runner を選ぶ を参照)。
3. Runner がタスクのコンテキストを取得します。依頼の場合は、その文面、追加されたコンテキスト、それまでの会話です。例外の場合は、その種類、メッセージ、スタックトレースです。
4. リポジトリを専用のワークスペースにクローンし、ブランチを作成します。例外の修正のブランチ名は、oneuptime-fix-exception- の後に実行 ID の先頭の文字が続くものです。依頼は、依頼したときに選んだブランチから始まり、プルリクエストはそのブランチに向けて作成されます。返信の場合は、代わりにタスクの開いているプルリクエストのブランチで作業します。
5. プロジェクトの LLM プロバイダーで動くコードエージェントが、コードを読んで変更を書きます。LLM の呼び出しは Status200 サーバーが行うため、Runner がプロバイダーの API キーを持つことはありません。また、すべての呼び出しは計測され、AI ログに表示されます。例外、遅いトレース、インシデントの修正は、作業しながら本番環境も読みます。読むのは、リポジトリのサービスの例外、トレース、ログ、メトリクスです(修正での本番テレメトリ を参照)。
6. 独自の Runner では、コードエージェントは何かがコミットされる前に、リポジトリの AGENTS.md が示すとおりに変更をビルドしてテストし、失敗したところを修復します(プルリクエスト前の検証 を参照)。
7. Runner がコミットし、ブランチをプッシュし、プルリクエストを作成して(依頼の場合はコードを変更したときだけ)、ワークスペースを削除します。

タスクを開始したページに、その状態がリアルタイムで表示されます。すべてのタスクは 製品 → コード のリポジトリごとに一覧表示されます。タスクのページはその会話で、各ターンの ログ には、Runner が読み書きしたファイルと実行したコマンドごとに 1 行が記録されます。

各実行には、サーバーが強制する予算があります。上限は LLM 呼び出し 40 回 と 出力トークン 100,000 個 です。実行が本番テレメトリに対して行うクエリも、同じ 40 回の呼び出しに数えられます。いずれかに達した実行は、ループし続けるのではなく、それまでの作業のまとめで終了します。プロジェクトが 1 日あたりの AI の上限を設定している場合は、修正の実行もその上限に数えられます。

修正タスクの開始場所#

これらのボタンは、タスクを開始できる場所にだけ表示されます。プロジェクトの AI がオフのときはどれも表示されず、例外のサイドメニューに AI アシスタンス はありません。ログ出力を改善 と トレースを改善 はリポジトリが接続されると表示され、AI でパフォーマンスを修正 は修正する価値のあるトレースにだけ表示されます（トレースエクスプローラー を参照）。関数の AI で修正 は、プロファイルの時間またはメモリの 5% 以上を占めるか、比較対象の期間から割合が 3 ポイント以上増えた、アプリケーション自身のコードにだけ表示されます（継続的プロファイリング を参照）。

例外の AI アシスタンス ページを開くには、製品 → オブザーバビリティ → 例外 で例外を開き、サイドメニューで AI アシスタンス を選びます。解決済みまたはアーカイブ済みの例外は、先に未解決としてマークする必要があります。

Status200 AI は修正タスクを自ら開始することもあります。コードの変更を見つけた調査から、テレメトリが不足していたために結論が出ずに終わった調査から、そして例外や遅いトレースについての AI Insights からです。それぞれに専用のスイッチがあります。自動コード修正 を参照してください。

修正での本番テレメトリ#

Status200 はコードが本番環境で何をしているかを把握しているので、修正はスタックトレースだけを頼りに作業する必要がありません。コードエージェントは作業中に、リポジトリに対応するサービスの本番テレメトリをクエリできます:

プルリクエストの説明には、エージェントが何をクエリし、何がわかったかが書かれます。回帰テストやログ出力・トレースの改善など、ほかのタスクは本番環境をクエリしません。

エージェントが何を読めるかは、タスク自体をもとに Status200 サーバーが決めます:

• 読み取り専用。 クエリは Runner ではなく Status200 サーバーで実行されます。Runner はテレメトリを読む認証情報を持っていません。クエリによってプロジェクトが変更されることは一切ありません。
• このプロジェクトの、このリポジトリに対応するサービスだけ。 対応付けを設定する必要はありません。対象は、Status200 が修正のリポジトリを見つけるのと同じ方法で、このリポジトリに対応すると判断したサービスです。つまり、サービスの例外のスタックトレースがこのリポジトリのファイルを通っている、サービスの名前がリポジトリと同じ、またはこれがプロジェクトで唯一のリポジトリである、のいずれかです。ほかのサービスのテレメトリは読めません。
• 非公開のインシデントは対象外で、トークン、キー、パスワード、メールアドレスは、Status200 AI がデータを読むほかの場所と同じく、エージェントが結果を見る前に伏せられます。
• 上限あり。 クエリは実行ごとに最大 12 回で、それぞれが実行の 40 回の呼び出しに数えられます。

リポジトリに対応するサービスがない場合、タスクはこれまでどおり本番テレメトリなしで実行されます。

プルリクエストの本番レビュー#

Status200 はコードが本番環境で何をしているかを把握しているので、差分を読むだけではわからないことをもとにプルリクエストをレビューできます。コードのリポジトリの 設定 ページの その他の設定 で 本番環境のデータでプルリクエストをレビュー をオンにすると、書き込み権限のある人がプルリクエストを作成またはプッシュするたびに、変更されるコードについて本番環境が示すことを伝えるコメントがひとつ付きます。コメントはプッシュのたびにその場で更新され、コードのリポジトリの 本番レビュー ページには各レビューが 再レビュー とともに残ります。

本番環境が何かを示している場合、Status200 AI がそれを差分と並べて読み、注意すべき点 を加えます。それぞれ事実に基づく、短いポイントがいくつか並びます。これはプロジェクトで AI がオンのときだけ、プルリクエストごとに一日 10 回、リポジトリごとに一日 100 回までしか実行されず、ほかの AI 呼び出しと同じように計測されます。事実は AI なしで毎回読み取られます。本番環境が変更について何も示していない場合、Status200 は何も投稿しません。

• 集計値のみ。 コメントに含まれるのは件数、所要時間、コードの名前だけです。例外のメッセージ、ログ行、インシデントのタイトル、個人データは決して含まれません。
• 公開リポジトリにはリンクだけ。 公開リポジトリのプルリクエストは誰でも読めるため、そこではコメントは Status200 のレビューへのリンクだけになり、レビューはプロジェクトのメンバーだけが開けます。リポジトリの 設定 ページの その他の設定 にある 本番レビューのコメント では、すべてのリポジトリで レビューへのリンクのみ を投稿するか、公開リポジトリでもレビューを表示 を選べます。
• 外部のコントリビューターは開始できません。 プルリクエストが自動でレビューされるのは、作成者とプッシュした人がリポジトリに書き込める場合だけです。それ以外の人 - 外部のコントリビューター、フォーク、ボット - のプルリクエストは、書き込み権限のある人が @oneuptime production review とコメントするか、コードで 再レビュー を押したときにレビューされます。
• 読み取り専用。 レビューは何もクローンせず、プルリクエストのものは何も実行しません。差分とタイトルは Status200 AI にとってデータであり、指示ではありません。AI はツールを持たず、AI が書いたものはテキストとしてコメントに入ります。

このスイッチは、これから GitHub App が接続するリポジトリではオンになります。この機能より前に接続されたリポジトリでは、オンにするまでオフのままです。

プルリクエスト前の検証#

リポジトリは、ルートにある AGENTS.md(コーディングエージェントが読むファイル)に、ビルドとテストの方法を書いています。コードエージェントは何かを変更する前に、タスクの起点となるブランチからリポジトリの AGENTS.md(AGENTS.md がない場合は CLAUDE.md)を読み、そこに書かれたとおりに作業します。どちらもない場合は、リポジトリの CONTRIBUTING.md、README、パッケージのスクリプト、Makefile、CI のワークフローから方法を把握します。Status200 で設定することは何もありません。

フォークから来たプルリクエストの内容が、リポジトリの指示として読まれることはありません。修正はそのようなプルリクエストを拒否し、レビューはベースブランチを読みます。

リポジトリに設定されたコマンド#

コードはもうセットアップ・ビルド・テストのコマンドを求めませんが、以前に、または API や Terraform で設定されたコマンドを持つリポジトリは、それを保持します。リポジトリの 設定 ページの その他の設定 にある ビルド・テストのコマンド カードに読み取り専用で表示され、コマンドを削除 で 3 つとも削除できます。いずれかが設定されている間は、独自の Runner での各修正の実行は、プルリクエストを作成する前にそれらでも変更を確認します。

1. コードエージェントが終わると、コマンドが順番に、Runner 上のクローンしたワークスペースで、リポジトリのルートから実行されます。各コマンドには最大 15 分が与えられ、CI=true で実行されるため、入力待ちになることはありません。最初の失敗でその回は止まります。
2. 失敗した場合、失敗したコマンドの出力の末尾が修復タスクとして同じコードエージェントに戻され、テストを弱めたりスキップしたりせずに自分の変更を直すよう指示されて、コマンドがもう一度実行されます。修復は最大 2 回までです。修復は実行の LLM 予算を共有し、その編集は修正と同じコミットに入ります。
3. 結果(合格、失敗、またはコマンド未設定かグローバル Runner によるスキップ)は、プルリクエストの説明の Verification セクションに書かれ、タスクのプルリクエストに記録されます。

検証に通らないままの変更は捨てられません。プルリクエストはそれでも作成され、失敗したコマンドを示してその出力で終わる、はっきりと目立つ "Verification failed" セクションが付きます。作業は残り、判断するのはレビュアーです。コマンドが設定されていないリポジトリは、ビルドが成功したかのように見せるのではなく、スキップとして報告されます。

コマンドはチームが書くリポジトリの設定で、あなた自身の Runner 上で実行されます。Runbook の Bash ステップと同じ信頼モデルです。AI がそれらを書いたり変えたりすることはありません。Status200 がすべてのプロジェクトのために動かすグローバル Runner は、これらを実行しません。グローバル Runner では、修正は書かれてレビューのために開かれ、検証はスキップとして報告され、リポジトリ自身の CI が変更を確認します。プルリクエストが開く前に修正をビルドしてテストするには、独自の Runner を実行してください。

修正がマージされた後#

修正はマージしただけでは何も直さず、動いて初めて直します。修正のプルリクエストがマージされると、Status200 はそれを含む記録済みのデプロイを待ち(デプロイと変更 を参照)、そのデプロイで修正の目的を見守ります。結果は Code のタスクのプルリクエストに表示され、例外の AI アシスタンス ページ、インシデントの AI ログ、修正のもとになった AI インサイトにも表示されます。

デプロイで届けられるまでは マージ済み、デプロイ待ち と表示され、見守っている間は デプロイ済み、本番環境で監視中 と表示されます。14 日以内にどの記録済みデプロイにも含まれなかった修正や、本番環境から判断できない修正は 本番環境で未検証 と表示されます。ルールは 自動コード修正 にあります。回帰テスト、エラー処理の改善、レビュー、Code での依頼は見守りません。本番環境では、それらが何を変えたかを示せないためです。

始める前に#

タスクには 3 つのものが必要です。コードの依頼欄と、例外の AI アシスタンス ページは、開始を提案する前に 3 つすべてを確認し、何が足りないかを示します。

セルフホストのインスタンスでは、グローバルプロバイダーは config.env(Docker Compose)または Helm の values の 1 ブロックです。セルフホストの Ollama の場合:

GLOBAL_LLM_PROVIDER_TYPE=Ollama
# An address the Status200 server can reach, never localhost.
GLOBAL_LLM_PROVIDER_BASE_URL=http://ollama:11434
GLOBAL_LLM_PROVIDER_MODEL_NAME=llama3.1
# No GLOBAL_LLM_PROVIDER_API_KEY needed — Ollama is keyless.

サポートされているどのプロバイダーでも動作します。すべてのプロバイダーと各環境変数については LLM プロバイダー を参照してください。

リポジトリをサービスに対応付ける必要はありません。タスクが開始すると、Status200 は例外のスタックトレースのファイルパスを接続済みのリポジトリと照合してリポジトリを見つけます。一致するものがなければ、サービスと同じ名前のリポジトリを使い、それもなければ、プロジェクトにリポジトリが一つしかない場合はそれを使います。AI アシスタンス ページに、見つかったリポジトリが表示されます。

リポジトリの Runner を選ぶ#

各リポジトリは、AI がそこで作業する Runner を選びます。コードのリポジトリの 設定 ページで その他の設定 を開き、Runner カードの 編集 をクリックして選択します。GitHub App がインポートしたリポジトリは、プロジェクトに デフォルトの Runner があれば、それで始まります。何も選んでいないリポジトリは、Status200 がすべてのプロジェクトのために動かす グローバル Runner で作業します。

リポジトリのタスクとそのトークンを受け取るのは、そのリポジトリが選んだ Runner だけです。Runbook → Runner で グローバル Runner を使用 をオフにしたプロジェクトでは、すべてのリポジトリにプロジェクト自身の Runner が必要です。Runner のページには、それを選んでいるリポジトリが一覧表示されます。

独自の Runner を実行する#

Runner を別の場所、たとえばリポジトリに近いマシンで実行するには:

1. Runner を作成する#

   Runbook → Runner で Runner を作成し、その行の セットアップ手順を表示 をクリックします。コマンドには Runner のシークレットキーが含まれており、これを読めるのは Project Owner、Project Admin、Runbook Admin だけです。次のようになります:

   Bash

   docker run --name status200-runner --restart unless-stopped \
     -e STATUS200_RUNNER_ID=<runner-id> \
     -e STATUS200_RUNNER_KEY=<runner-key> \
     -e STATUS200_URL=<your-status200-url> \
     -d status200/runner:release

2. リポジトリ用に選ぶ#

   コードのリポジトリの 設定 ページで その他の設定 を開き、Runner カードの 編集 をクリックして Runner を選びます。Runner は次の heartbeat で変更を反映します。およそ 1 分以内で、再起動は不要です。

3. 接続を確認する#

   1、2 分以内に、Runner は Runbook → Runner ページで接続済みとして表示されます。表示されない場合は、コンテナのログ(docker logs status200-runner)で認証情報やネットワークのエラーを確認してください。

コンテナの実行方法は問いません(Docker Compose、Kubernetes など)。これらの変数があり、HTTPS で Status200 インスタンスに到達できれば動作します:

調査からの自動コード修正#

AI 調査 がインシデントやアラートに根本原因の分析を投稿し、その慎重な分類がコードの変更を勧めた場合、調査カードに この分析から修正 PR を作成 が表示されます。投稿された分析をコンテキストのすべてとする修正タスクです。対策が運用上のもの、インフラだけのもの、外部のもの、想定内の拒否、ユーザーのミス、または結論が出ていない場合、このボタンは表示されません。インシデント → AI → 設定 の 新しいインシデントを自動的に修正する (および アラート → AI → 設定 の 新しいアラートを自動的に修正する) がオンの間は、対象となる修正がクリックなしで行われます。修正は最初はオフで、新しいプロジェクトでも同じです。AI ルールがなければ対象となる修正はすべて作成され、ルールがある場合は、ルールに一致したものについて、そのルールで 修正のプルリクエスト がオンのとき(新しいルールではオンです)、ルールが指定したコードリポジトリにだけ作成されます。

修正がオンの間、コードの変更で直せる、確かで根拠のある根本原因で終わった調査は、ボタンが作成するのと同じ修正タスクをキューに入れます。この判断はサーバーが確認する制約付きの分類であり、分析のテキストに対するパターン照合ではありません。プルリクエストを作成するのは、コード修正についての肯定的な判定だけです。根拠の不足、コード以外の対策、分類の失敗は、いずれも何もせずに終わります。

それ以外はボタンと同じです:

• プルリクエストはレビュー可能な状態で作成され、投稿された分析をもとに書かれます。GitHub App で接続されたリポジトリ(一致したルールが指定している場合はそのいずれか)と、そこで作業するためにオンラインの Runner(リポジトリが選んだもの、またはグローバル Runner)が必要です。
• そのシグナルの 1 日あたりの修正タスクの上限(1 日あたりのインシデントの AI 修正タスクの上限 または 1 日あたりのアラートの AI 修正タスクの上限、AI 設定ページの その他の設定 にあります)と、リポジトリのオープンなプルリクエストの上限に、設定されていれば数えられます。未設定なら、どちらも何も制限しません。
• 各トリガーはまず、同じインシデントまたはアラートについて、すでにキューにある、または実行中の修正タスクを探します。そのため、自動トリガーとクリックは通常、2 つのプルリクエストではなく 1 つのタスクになります。この確認は書き込み前の読み取りであり、ロックではないため、まったく同じ瞬間の 2 つのトリガーが両方とも通ることはあり得ます。
• 実行はシステムによって作成され、誰の功績にもならず、何も自動ではマージされません。

修正が失敗したとき#

プライバシー#

リポジトリのクローンは Runner のコンテナ内のワークスペースに置かれ、実行が終わると成功・失敗にかかわらず削除されます。Runner が LLM プロバイダーの API キーを持つことはなく、LLM の呼び出しは Status200 サーバーが代わりに行い、本番テレメトリのクエリもサーバーが実行します。Status200 はリポジトリを保持せず、コードで学習することもありません。タスクのログには各ステップの出力の先頭 300 文字が残り、Runner が何をしたか確認できますが、そこにはコードの一部が含まれることがあります。独自の LLM プロバイダー(ローカルの Ollama を含む)でセルフホストの Runner を実行すれば、コードがインフラの外に出ることはありません。

ロードマップ#

予定されており、現時点では利用できません:

• GitLab のサポート。 リポジトリの接続は GitHub App のみです。

次のステップ#