AIエージェント自動化の事例4つ、対話ではなく目標を任せる

Claude CodeやCodexのようなAIエージェントを使っていると、ターミナルの前に座って1ターンずつ対話しながら仕事を頼むことになりますよね。この記事では、対話の代わりに目標だけ渡せばエージェントが自分で作業するAIエージェント自動化の事例4つと、それらに共通する方法を整理しました。

まず告白しておきます。私も2026年3月に「アイデアファイルを置いておくと、PMエージェントがタスクに分け、開発エージェントが実行する」パイプラインを設計しました。でも、この設計は実際には動きませんでした。そこで今回は自分の設計ではなく、今実際に動いていて、公開ドキュメントで確認できる事例だけを選びました。

対話で頼むことと目標で頼むこと#

ターミナルで対話しながら仕事を頼むと、人がずっとその場にいなければなりません。エージェントが1ステップ終えるたびに次の指示を出し、結果を確認し、また指示する、という繰り返しだからです。

目標で仕事を頼む方式は順番が逆です。人は何を望んでいるか、何をもって完了とするかをIssueやファイルに残して席を離れます。エージェントはそれを読んで作業し、結果をPRや実行記録として返します。

事例1：Issueを割り当てるとPRが返ってくる#

いちばん始めやすいのは、GitHubのIssueをエージェントに任せる方法です。同僚にIssueを渡すようにエージェントに渡すと、エージェントがブランチを作って作業し、PRで結果を持ってきます。

GitHub CopilotにIssueを割り当てる#

GitHub Copilotは、IssueのAssigneesでCopilotを選ぶと作業を始めます。公式ドキュメントによると、Copilotは作業を始めてPRを作成し、終わったら人にレビューを依頼します。修正が必要なら、PRのコメントで@copilotにメンションします。

ドキュメントには注意点が1つあります。割り当てた後にIssueに追加したコメントは、Copilotには見えません。そのため割り当てる前に、望む結果、使うパターン、テストの要件、触ってはいけないファイルまで、Issue本文にすべて書いておく必要があります。また、デフォルト設定ではCopilotがPRにpushしてもGitHub Actionsのワークフローはすぐには動きません。人が変更内容を確認してApprove and run workflowsを押すと実行されます。

Claude Code GitHub Actionsで@claudeを呼ぶ#

Claude Code GitHub Actionsは、リポジトリのワークフローの中でClaude Codeを実行します。IssueやPRのコメントで@claudeにメンションすると、Claudeがコードを分析し、変更を実装し、コミットをpushします。セットアップはClaude Codeで/install-github-appを実行すると、アプリのインストール、シークレットの登録、ワークフローPRの作成まで案内してくれます。

@claude implement this feature based on the issue description
@claude fix the TypeError in the user dashboard component

リポジトリのルートにCLAUDE.mdを置くと、ClaudeはPRを作るときにその中のコードスタイルやルールに従います。毎回対話で説明していたルールを、ファイル1つに移しておくようなものです。

事例2：決まった時間に自分で作業を始める#

Issueの割り当ても、結局は人が「今やって」と押すことです。繰り返しの作業なら、トリガーそのものをスケジュールに任せることができます。

Claude Code GitHub Actionsの定期実行#

Claude Code GitHub Actionsは、ワークフローにpromptを入れるとメンションを待たない自動化モードで動きます。cronのスケジュールと組み合わせれば、毎日決まった時間に同じ目標で作業を始めます。以下は公式ドキュメントの例で、毎日09:00（UTC）に前日のコミットとオープンなIssueを要約します。

name: Daily Report
on:
  schedule:
    - cron: '0 9 * * *' # 毎日09:00 UTC
jobs:
  report:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: read
      id-token: write
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          # この1文がエージェントに渡す目標です
          prompt: "Generate a summary of yesterday's commits and open issues"
          # 目標に必要なツールだけを許可します
          claude_args: |
            --allowedTools "mcp__github__list_commits,mcp__github__list_issues"

promptだけを渡しても、ClaudeはシェルやGitHub APIを使えません。目標に必要なツールを--allowedToolsで明示的に許可する必要があります。コストを抑えるには、--max-turnsで反復回数を制限し、ワークフローにタイムアウトを設定するとよいとドキュメントに書かれています。

Multica AutopilotsのRunbook#

私が今エージェントの作業管理に使っているMulticaにも、同じ役割を果たすAutopilotsがあります。Autopilot 1つには、目標、背景、制約、手順を書いたRunbookと、担当エージェント、トリガーが入ります。

トリガーは、決まったスケジュール、外部システムから届くWebhook、手動実行の3種類です。トリガーがかかると、Issueを作ってエージェントに割り当てるか、Issueなしでエージェントを直接実行します。ドキュメントの例は、毎週月曜09:00の顧客フィードバックのまとめ、毎日の進捗サマリー、定期的な依存関係のチェックなどです。

事例3：Ralphループで目標ファイルを渡し続ける#

Ralphは、Geoffrey Huntleyが2025年7月に紹介した方法です。核となるのは、本当に1行のBashループです。

# 同じ目標ファイルをエージェントに延々と渡し続けます
while :; do cat PROMPT.md | claude-code ; done

ループが回るたびに、エージェントは新しいコンテキストで始まります。そのため記憶は対話ではなくファイルに残します。事前に対話で作っておいたスペック（specsフォルダ、1ファイルに1スペック）、優先順位付きのTODOリストfix_plan.md、ビルド方法を書いたAGENT.mdを、毎回同じ方法で読み込みます。

Huntleyが強調するルールは次のとおりです。

• 1ループに1つだけ — TODOリストからいちばん重要な項目を1つだけ処理します。
• バックプレッシャー（backpressure） — テスト、静的解析、型チェックで間違った結果をはじきます。
• 進捗はgitで — 終わった作業はコミットし、ビルドとテストが通ったらタグを付けます。
• 間違えたらプロンプトを直す — エージェントが同じミスを繰り返すなら、ツールのせいにするよりプロンプトに「標識」を足します。

ただしHuntley本人も、Ralphは新規プロジェクト（greenfield）にいちばん向いていて、既存のコードベースには使わないと言っています。エンジニアはもう要らないという主張にも、はっきり線を引いています。

事例4：数時間かかる作業はハーネスでつなぐ#

Anthropicは2025年11月、エンジニアリングブログで長時間実行エージェントのためのハーネス（harness）を公開しました。高レベルのプロンプト1つでWebアプリを最後まで作らせようとしたところ、エージェントは2つのパターンで失敗したそうです。

1. 一度に作りすぎてコンテキストが尽き、機能を作りかけのまま記録もなく終わりました。
2. 次のセッションのエージェントが、すでにできているものを見てプロジェクトは完了したと宣言しました。

解決策は、エージェントを2つの役割に分けることでした。

• 初期化エージェント（initializer agent） — 最初のセッションでだけ動きます。開発サーバーを起動するinit.sh、作業記録ファイルclaude-progress.txt、最初のgitコミットを作ります。そしてスペックをもとに機能リストをJSONで書きます。
• コーディングエージェント（coding agent） — それ以降のすべてのセッションで動きます。記録ファイルとgitログを読み、まだ合格していない機能のうち優先度がいちばん高いものを1つだけ実装します。

機能リストの項目はこんな形です。claude.aiのクローンの例では、こうした項目が200個以上あり、最初はすべてpasses: falseから始まります。

{
  "category": "functional",
  "description": "機能の説明",
  "steps": ["検証ステップ1", "検証ステップ2"],
  "passes": false
}

コーディングエージェントが変更できるのはpassesの値だけです。記事によると、JSONを選んだのは、Markdownよりもモデルが不適切に書き換える可能性が低いからでした。また、エージェントはユニットテストやcurlだけを見て完了扱いにすることが多かったのですが、ブラウザ自動化で人間のように実際に使って検証するよう指示すると、結果が大きく改善したそうです。

実際に動いている事例の共通点#

4つの事例を並べると、目標を任せる方法はいくつかにまとまります。

1. 目標は1か所に完結させて書く — Issue本文、prompt、Runbook、PROMPT.mdのように。任せた後に付け足した言葉は届かないことがあります。
2. 一度に1つだけ任せる — Ralphは1ループに1項目、Anthropicのハーネスは1セッションに1機能です。
3. 記憶は対話ではなくファイルとgitに残す — TODOリスト、進捗記録、コミットが次の実行の出発点になります。
4. 完了したかはエージェントの言葉ではなく検証で判断する — テスト、型チェック、passesフラグ、ブラウザでの検証といった仕組みがあります。
5. 人は結果をレビューする位置にいる — PRのレビュー依頼、実行記録、ワークフローの承認のように、人が確認するポイントが残っています。

私のIdea-to-Task設計が動かなかった理由#

私の3月の設計は、docs/ideas/にアイデアを書くと、PMエージェントがそれを監視してdocs/tasks/にタスクファイルを作り、割り当てエンジンが開発エージェントに振り分ける構成でした。似たMarkdownベースの自動化を実際に作って回してみたところ、人がノートを書くだけで終わる絵にはなりませんでした。結果の品質、管理の負担、パイプラインの保守の問題は、MarkdownでAIエージェントの作業を自動化するときに押さえることにまとめています。

上の事例と比べると違いが見えます。事例はどれもGitHubのIssue、Actions、gitのようにすでにあるツールの上に載せていて、完了を判断する仕組みがはっきりしています。私の設計は、フォルダの監視、PMエージェント、割り当てエンジンを新しく作る必要がありました。タスクファイルにも何を作るかだけが書かれていて、完了を判断する条件や検証方法は書かれていませんでした。

小さく始める方法#

最初からパイプラインを作る必要はありません。今あるリポジトリ1つにClaude Code GitHub ActionsかCopilotをつなぎ、ターミナルで対話しながら説明していた内容を、完了条件まで書いたIssue 1つに移して任せてみてください。Issueを指示書としてうまく書く方法は、ObsidianのノートをAIエージェントの作業指示書として使うの目標、文脈、完了条件、やらないことの構成をそのまま使えます。

Be a good listener. Your ears will never get you in trouble.

— Frank Tyger