マネージドエージェント実行

マネージドエージェント実行を使うと、Archylから直接自律型AIエージェントを起動できます。タスクを指定し、エージェントの振る舞いを決めるプロファイルを選び、MCPコネクタで外部サービスと接続し、定期スケジュールを設定すれば、エージェントが完全なアーキテクチャコンテキストを持ってコードベース上で作業を行います。

サイドバーの エージェントハブ → 実行一覧 で実行を管理し、エージェントハブ → プロファイル でエージェントの振る舞いを定義し、エージェントハブ → スケジュール で定期的な自動化を設定します。

概要

マネージド実行は、単一のエージェント実行です。エージェントは以下の処理を行います:

1. クローン — プロジェクトのリポジトリを、エージェントワーカー上の新しいワークスペースにクローンします
2. コンテキストの受信 — アーキテクチャコンテキスト(C4モデル、ADR、適合性ルール、APIコントラクト、技術スタック)に加え、作業セッションのブリーフィングを受け取ります。ブリーフィングには、タスクが関わる要素、過去のセッションがそれらについて学んだこと、プリフライトの判定が含まれます
3. タスクの実行 — 定義されたタスクを実行し、プロファイルの制限の範囲内でツールを呼び出して意思決定を行います
4. 結果の公開 — コードの変更をプルリクエストとして公開し、すべてのアクションの完全なトレースを報告します

実行は手動(ワンショット)またはスケジュールによる自動トリガーが可能です。

実行の開始

1. エージェントハブ → 実行一覧 に移動します
2. ドロップダウンからプロジェクトを選択します
3. 新規実行 をクリックします
4. プロファイルを選択します
5. タスクの説明を記述します(例: "Check for stale dependencies and create a summary")
6. 必要に応じてコネクタを追加します(下記参照)
7. 実行を開始 をクリックします

エージェントは即座に作業を開始します。実行詳細ページでリアルタイムに進捗を確認できます。

エージェントプロファイル

プロファイルは、エージェントの振る舞いを再利用可能な形で定義したものです。すべての実行とすべてのスケジュールが、いずれかのプロファイルを使用します。初回アクセス時に Archyl が組織用の backend-fixer プロファイルを作成します。追加のプロファイルは エージェントハブ → プロファイル で作成できます。

プロファイルを削除しても、そのプロファイルで行われた実行の履歴は残ります。そのプロファイルを使っていたスケジュールは一時停止され、プロファイル削除済み と表示されます。再開するには、スケジュールで別のプロファイルを選択してください。

スキル

スキルは Archyl が管理するプレイブックで、エージェントが実際に使えるツールに合わせて常に更新されています。指示をプロンプトにコピーする代わりに、プロファイルごとに有効化してください。

不明なスキルや無効な許可ツールのパターンを含むプロファイルは、保存時に拒否されます。

デフォルトの backend-fixer プロファイルでは、Architecture memory、Conformance first、Decision records が有効になっています。

実行詳細ページ

各実行には以下の情報を表示する詳細ページがあります:

イベントフィードには、各アクションの展開可能なカードが表示されます:

• ツール呼び出し — ツール名、入力パラメータ、出力を表示します。各カードには、ツールの提供元コネクタを示すソースラベルが表示されます(例: github、archyl、linear)。
• メッセージ — エージェントの推論と意思決定の内容。
• 結果 — 実行結果、トークン使用量、プルリクエスト、エージェントが変更したファイル。
• エラー — 迅速な特定のためにハイライト表示されます。

実行中のエージェントに指示する

実行中は、指示ボックスにメッセージを入力すると、実行をキャンセルせずにエージェントの方向を修正できます(例: 「マイグレーションは飛ばして、ハンドラーに集中して」)。メッセージはすぐにキューに入り、エージェントの次のステップで会話に挿入されます。エージェントが受け取ると、フィードに ステアリングメッセージがエージェントに届きました と表示されます。

実行が途中で止まった場合

実行が失敗した場合や、コストや時間の上限に達した場合、反復回数を使い切った場合でも、それまでの作業は失われません。Archyl はその作業を、実行が止まった理由を記載した ドラフト のプルリクエストとして公開します。詳しくは下の プルリクエスト を参照してください。ユーザーがキャンセルした実行は何も公開しません。

信頼性の保証

• 停止したワーカーを検知します。 エージェントワーカーは10秒ごとに応答を送ります。ワーカーから3分間応答がない実行や、時間の上限を10分過ぎても動き続けている実行は、自動的に failed となり、その枠が解放されます。
• 停滞した実行が枠を占有し続けることはありません。 10分以内にどのエージェントワーカーにも取得されなかった実行は失敗します。人の応答を1時間10分を超えて待ち続けた実行も同様です。
• 認証情報は実行より長く残りません。 各実行には専用の短期間有効な Archyl API キーが発行され、実行が終わるとすぐに失効します。
• キャンセルは確実にエージェントに届きます。 直接の停止リクエストがワーカーに届かなかった場合でも、キャンセルされた実行は次の応答時に停止します。

作業セッションと連携

すべての実行は Archyl の作業セッションの中で行われます。これは Archyl Harness がローカルのコーディングエージェントに提供しているのと同じプロトコルです。セッションの開始と終了はプラットフォームが行い、エージェントがセッションを管理することはありません。

実行の作業セッション

実行が始まると、Archyl はタスクが関わるアーキテクチャ要素を対象にセッションを開きます。それらの要素のリースを取得し、プリフライトゲートの判定（allow、warn、deny）を算出して、関連する決定事項・ガードレール・メモリをエージェントのブリーフィングに含めます。判定はイベントフィードに ゲート イベントとして表示されます。

他のエージェントの作業を尊重する

他のエージェントの作業を尊重する はプロファイルの 連携 にある設定で、既定ではオフです。オンにすると、セッションは排他的に開かれます。

• 別のエージェントが要素を保持している場合。 Claude Code のようなコーディングエージェントや別のマネージド実行が同じ要素のリースを保持していると、実行は拒否されます。理由には、誰がそこで作業しているかが示されます。
• ゲートが警告のみの場合。 たとえば error レベルのガードレールが該当するときは、実行は 承認待ち の状態で待機し、その間は同時実行枠を消費しません。実行ページには理由とともに 承認して開始 と 実行をキャンセル が表示されます。

承認するとゲートが再チェックされ、その間に発生した競合があれば実行はやはり拒否されます。24 時間以内に誰も承認しなかった実行はキャンセルされます。

設定がオフの場合、ゲートの判定にかかわらず実行は開始され、エージェントはブリーフィングで理由を確認します。

ファイル書き込みの Guard

エージェントがリポジトリで作業するときは、プロジェクトにリンクされたリポジトリでも GitHub コネクタで開いたリポジトリでも、write_file と edit_file の呼び出しはすべて、変更が反映される前にプロジェクトの適合性ルールと照合されます。

チェック自体が失敗した場合、書き込みは通ります。Guard が自身のエラーでエージェントを止めることはありません。この挙動はローカルのコーディングエージェント向けの Guard フックと同じで、Harness ガイドで説明しています。

作業セッションの成果

エージェントは終了前に成果を報告します。内容は要約、決定事項、フォローアップ、そして参考にしたメモリです。実行が終わると、Archyl は次の処理を行います。

1. 変更されたファイルをセッションに紐づけ、実際の作業がどのリース対象要素に及んだかを特定します
2. セッションを閉じ、要約をそれらの要素のメモリとして保存します
3. 決定事項をプロジェクトのメモリとして記録し、レビュー用にアーキテクチャ変更リクエストのドラフトを作成します。決定事項を記録するのは成功した実行だけです

実行ページには 作業セッションの成果 カードが表示され、要約、決定事項、フォローアップ、関わった要素、変更リクエストへのリンクが並びます。別のセッションが保持している要素には 別の作業セッションが保持中 の印が付きます。

実行をリアルタイムで追う

実行ページには、イベントフィードである アクティビティ と、エージェントが書き込んだファイルを示す 変更 の2つのビューがあります。エージェントがあなたの対応を必要としているときは、その上にバナーが表示されて何を待っているか(計画のレビューを待っています または エージェントから質問があります)を示し、該当する場所へ案内します。

計画

エージェントは何かを変更する前に計画を共有します。計画は1文の要約と、最大12個の具体的なステップで構成されます。実行ページ上部の 計画 パネルは、これをチェックリストとして表示します。エージェントは各ステップを 進行中、完了、スキップ のいずれかにし、短いメモを添えることもあります。パネルには現在のステップと進捗(3/7)が表示されます。

先に計画をレビューする はプロファイルの 連携 にある設定で、既定ではオフです。オンにすると、エージェントは何かを変更する前にレビューを待ちます。

1. パネルが 計画をレビュー に切り替わります。ステップの名前変更や詳細の追加に加え、ステップの追加、削除、並べ替えができます。
2. 計画を承認(編集した場合は 編集した計画を承認)すると、エージェントが作業を進めます。編集したバージョンが、エージェントが従い、チェックリストが追跡する計画になります。
3. 変更を依頼 すると、フィードバックが送られます。エージェントは計画を修正し、レビュー用の新しいリビジョンを提案します。以前のリビジョンはフィードに残ります。

計画が承認されるまで、エージェントは読み取りはできますが、何も変更できません。ファイルの書き込みと、作成・更新・削除・リンク・インポート・プッシュ・マージを行うツール(Archyl でもすべてのコネクタでも。例: linear__create_issue)は拒否され、remember も同様です。エージェントにはレビューを待つよう伝えられます。

質問

要件があいまいな場合、明確な正解のないトレードオフがある場合、破壊的な操作を伴う場合など、人の判断が必要なときは、エージェントが質問します。質問はフィードの上に表示され、エージェントが候補を示した場合は 回答の候補 も並びます。自由記述の回答欄もあり、Cmd/Ctrl + Enter で送信できます。プロジェクトを編集できる人なら誰でも回答でき、誰が回答したかはフィードに記録されます。

エージェントが1回の実行でできる質問は最大5件です。また、自分で調べられることは決して質問しないよう指示されています。

あなたの対応待ち

エージェントが計画のレビューや回答を待っている間、実行には あなたの対応待ち と表示され、実行一覧では 承認待ち で保留中の実行とともに 対応が必要 の下に表示されます。

• 待機時間は実行の時間上限に含まれず、待機した時間の分だけ期限が後ろにずれます。実行は同時実行枠を使用したままです。
• 1時間以内に誰も回答しなかった質問: エージェントは自身の判断で作業を続け、置いた前提を成果に記載します。
• 1時間以内に誰もレビューしなかった計画: 実行は何も変更しないまま失敗します。

エージェントの作業場所

エージェントは、リポジトリのクローンであるワークスペースでコードを読み、変更します。

• プロジェクトにリンクされたリポジトリ: 実行の開始時に Archyl がクローンします。
• リンクされたリポジトリがなく、GitHub コネクタが接続されている場合: エージェントはファイルに触れる前に、タスクの対象となるリポジトリをコネクタの認証情報を使って自らクローンします。対応しているのは GitHub のホスト型 MCP サーバー(api.githubcopilot.com)のみです。コネクタは Authorization: Bearer ヘッダーで認証する必要があり、そのトークンにはリポジトリへのアクセス権が必要です。

ワークスペースが開いた後は、エージェントはそこでのみファイルを変更します。コネクタのツールを使ったファイルのプッシュやプルリクエストの作成は拒否されます。これにより、すべての変更が Guard を通り、変更 ビューに表示され、1つのプルリクエストにまとまります。

変更

変更 には、エージェントが書き込んだファイルが書き込みと同時に一覧表示されます。各ファイルは 追加、変更、ブロック のいずれかで、ファイルごとと実行全体の追加行数・削除行数も表示されます。ファイルを選択すると、各書き込みで何が変わったかを確認できます。

• Guard が拒否した書き込みは ブロック になります。差分には、エージェントが書き込もうとした内容と違反したルールが表示されます。Guard が警告のみを出した書き込みは反映され、ファイルに警告が付きます。
• 長い差分は600行で打ち切られ、128 KB を超えるファイルは差分なしで表示されます。

行にコメントする

エージェントの作業中に差分をレビューできます。変更 で行番号をクリックしてその行にコメントし、エージェントに送信 をクリックします(Cmd/Ctrl + Enter)。エージェントはファイル、行、その内容を受け取り、コメントに対応してから計画の続きに戻ります。

• コメントは該当行の下に表示され、エージェントが読むまでは 送信待ち、読んだ後は 配信済み になります。アクティビティ にも表示され、各ファイルにはコメント数が表示されます。
• 追加行、変更のない行、削除行のいずれにもコメントできます。Guard がブロックした書き込みにはコメントできません。
• コメントは、エージェントが作業中またはあなたの対応待ちのときに受け付けられます。実行終了時にまだ 送信待ち のコメントは 未配信 と表示されます。

終了した実行では、コメントは次の実行へのメモになります。継続用に追加 でブラウザに保存され、ファイル一覧の上のバー(継続用のコメントが 3 件あります)から、それらのコメントで実行を継続できます(これらで継続する)。

プルリクエスト

実行が終了すると、Archyl はワークスペースの変更を archyl/agent- の後に実行 ID の先頭8文字を付けた名前のブランチにコミットし、クローン元のブランチに向けてプルリクエストを作成します。そのリンクは 変更 の上部(プルリクエストを開く)と結果に表示されます。

GitLab ではドラフトは Draft: マージリクエストになります。Bitbucket ではプルリクエストは作成せず、ブランチのみプッシュします。ファイルを1つも変更しなかった実行は何も公開しません。

プルリクエストは github.com、gitlab.com、bitbucket.org で作成されます。Archyl が Git の認証情報を送るのはこれらのホストだけです。セルフホストの Git サーバー(GitHub Enterprise、プライベートな GitLab、Azure DevOps、Gitea)上のリポジトリは認証情報なしでクローンされるため、プライベートリポジトリはクローンできず、プルリクエストも作成されません。

実行を継続する

終了した実行には、結果にかかわらず2つのボタンがあります。

• 継続 は、この実行の作業を引き継ぐ新しい実行を開始します。エージェントに次にしてほしいことを書いてください。継続用のコメントが1行に1件ずつ指示にあらかじめ入力されます(パス:行 — コメント)。プロファイルはデフォルトで元の実行と同じで、コネクタも選択できます。
• もう一度実行 は、同じタスクとプロファイルで開始ダイアログを開き、最初から新しく実行します。

継続した実行は、前の実行が何を依頼され、何をしたかを把握しています。前の実行が公開したブランチから開始してそこにコミットし、新しいプルリクエストを作らずに同じプルリクエストに変更を追加します。前の実行がプルリクエストを作成せずにブランチをプッシュしていた場合は、新しい実行が対象とするブランチに向けて、継続した実行がプルリクエストを作成します。前の実行が GitHub コネクタでリポジトリを開いていた場合は、そのブランチでリポジトリを開き直します。

• ブランチがもう存在しない場合(マージ後に削除された場合など)は、新しい実行が開始するブランチ(プロジェクトにリンクされたブランチ、またはリポジトリのデフォルトブランチ)から開始して新しいプルリクエストを作成します。その旨はフィードに表示されます。
• ドラフトのプルリクエストはドラフトのままです。作業が終わったらレビュー可能としてマークしてください。
• Archyl のエージェントが作成したブランチでのみ継続し、あなたのブランチにコミットすることはありません。

新しい実行のページには継続元の実行へのリンク(継続元の実行)が、前の実行には継続先の実行へのリンク(継続先の実行)が表示されます。実行中の実行は継続できません。代わりにその行にコメントしてください。

MCPコネクタ

コネクタを使用すると、エージェント実行に外部サービスを接続できます。MCP(Model Context Protocol)サーバーを公開するサービスであれば、どれでも接続可能です。

対応サービス

コネクタの作成

1. エージェントハブ → コネクタ に移動します
2. 新規コネクタ をクリックします
3. 名前を入力します(例: "github")
4. MCPサーバーのURLを貼り付けます
5. 必要に応じて認証ヘッダーを追加します
6. コネクタを作成 をクリックします — Archylがサーバーに接続し、利用可能なツールを表示します

ツールの名前空間

コネクタが実行に接続されると、そのツールにはコネクタ名がプレフィックスとして付与されます:

Archyl組み込みMCPサーバーのツールにはプレフィックスが付きません(例: get_agent_context、list_conformance_rules)。

この名前空間により、ツール名の衝突を防ぎ、イベントフィードを見やすくし、さらにプロファイルの許可するツールで github__* のような1つのパターンを指定するだけでコネクタ全体を対象にできます。

スケジュール

スケジュール機能を使用すると、標準的なcron式を使って定期的なエージェント実行を定義できます。

スケジュールの作成

1. エージェントハブ → スケジュール に移動します
2. 新規スケジュール をクリックします
3. プロファイルを選び、タスクの説明を記述します
4. cron式を選択します(プリセットが用意されていますが、カスタム入力も可能です)
5. 必要に応じてコネクタを追加します
6. スケジュールを作成 をクリックします

スケジュールの管理

各スケジュールには以下の情報が表示されます:

• Cron式 — エージェントの実行タイミング
• 次回実行 — 次の実行予定日時
• 前回実行 — エージェントが最後に実行された日時
• ステータス — アクティブまたは一時停止。プロファイルが削除された場合は プロファイル削除済み

以下の操作が可能です:

• 一時停止 — スケジュールを削除せずに停止します
• 再開 — 一時停止中のスケジュールを再開します
• 今すぐ実行 — 通常のスケジュール外で即座に実行します
• 編集 — タスクの説明、cron式、接続されたコネクタを変更します
• 削除 — スケジュールを削除します

プロファイルが削除されたスケジュールは一時停止のままです。スケジュールを編集して別のプロファイルを選ぶまで、再開も 今すぐ実行 も拒否されます。

スケジュールの例

アーキテクチャコンテキスト

すべてのマネージド実行は、ArchylプロジェクトのMCPサーバーへのアクセスが自動的に付与されます。エージェントは以下のことが可能です:

• C4モデルを照会してシステム境界を理解する
• ADRを参照して過去のアーキテクチャ上の意思決定を理解する
• 適合性ルールを確認して遵守すべきパターンを把握する
• APIコントラクトを参照してサービスインターフェースを理解する
• 技術スタックの割り当てを確認して適切なツールを選択する
• アーキテクチャメモリを通じて、要素に関する事実を呼び出し、記憶する

このコンテキストはエージェントの作業開始前に注入されるため、アーキテクチャをゼロから発見する必要はありません。また、各実行はハーネスの作業セッションに包まれているため、その結果は関わった要素のメモリとして残ります。

AI プロバイダー

組織で独自の AI プロバイダーを有効にしていない限り、実行には Archyl が管理するモデルが使われます。BYO を有効にすると、実行は独自のプロバイダー上で独自の認証情報を使って行われます。対応するのは Anthropic、AWS Bedrock、OpenAI、そして Responses API を実装した OpenAI 互換エンドポイントです。Google Gemini ではまだマネージドエージェントを実行できません。その場合、黙って Archyl のモデルに切り替えるのではなく、明示的なメッセージとともに実行が拒否されます。

クォータと同時実行

マネージドエージェント実行は Scale および Custom プランで利用可能です。使用量は組織単位で月次クォータとして追跡され、実行一覧ページとスケジュールページの上部に表示されます。実行の継続と、保留中の実行の承認も実行としてカウントされます。BYO AI を有効にしている組織は、手動実行・スケジュール実行のどちらもクォータに計上されません。

アクティブな実行(pending、running、または waiting_for_input)は、それぞれ組織の同時実行枠を1つ使用します。実行が終了すると、理由にかかわらずその時点で枠が解放されます。

ベストプラクティス

• タスクの説明は具体的に — "check dependencies" よりも "Check for Go packages with known CVEs and list them with severity" の方が効果的です
• ジョブごとに専用のプロファイルを用意する — allowedTools を list_*、get_*、read_file に限定した読み取り専用のレビュアーなら、誤って何かを変更することはありません。
• 必要なコネクタのみを接続する — コネクタを追加するたびにエージェントのコンテキストにツールが追加されます。ツールが少ないほど、より集中した実行が可能になります。
• まず手動実行でテストする — スケジュールを作成する前に、ワンショット実行でタスクの説明をテストしましょう。
• 適合性ルールと組み合わせて使う — まずガードレールを定義し、次に Conformance first スキルを有効にして、実行がそれらに対する検証を自動的に行うようにしましょう。