01 対話・コーディング型
Codex会話で目的を伝え、コードベースを読んで変更案を作り、必要ならテストやコマンド実行まで進める型です。提案・差分・実行結果を人が確認しながら使います。
向く例:知らないリポジトリの理解、機能追加、バグ修正、テスト
AI AGENTS × PATTERNS
「AIエージェント」と呼ばれていても、Codexのように会話からコード作業まで進めるもの、道具を使うもの、決まった手順の中で判断するもの、複数で分担するものがあります。名前を暗記するより、どこまで任せる仕組みかを見分けましょう。
分類にはいくつかの軸があります。この記事では、AIが答えを返すだけなのか、道具を選び、手順を進め、結果を確認するのかで整理します。呼び名に唯一の公式な分類表があるわけではありません。
Codexは会話から始められますが、コードベースを読み、変更案を作り、テストやコマンド実行まで進めるコーディングエージェントです。まずは提案と差分を見て、人が承認する使い方から始めます。
6つは別々の製品名ではありません。一つの仕組みが「ワークフロー型+単一エージェント型+定期実行型」のように、複数の特徴を持つこともあります。
会話で目的を伝え、コードベースを読んで変更案を作り、必要ならテストやコマンド実行まで進める型です。提案・差分・実行結果を人が確認しながら使います。
向く例:知らないリポジトリの理解、機能追加、バグ修正、テスト
検索、ファイル、データベース、APIなどを必要に応じて呼びます。ReActのように、考える流れと行動を交互に進める考え方もここに近いものです。
向く例:資料を探して根拠を抜き出す、CLIでファイルを確認する
全体の順番は人が決め、その一部の選別・分類・要約だけをAIに任せます。動きが説明しやすく、最初に試す型として扱いやすい方法です。
向く例:候補を集める→1件選ぶ→下書き保存→人が公開判断
一つのエージェントが、状態を見て道具を選び、結果を受け取り、完了するまで複数回動きます。道具を増やしすぎると、評価と原因追跡が難しくなります。
向く例:コードを読んでテストを実行し、エラーの候補を直す
調査、実行、検査などの役割を複数のエージェントに分けます。複雑な仕事を分担できる一方、引き継ぎ・重複・コストの管理が増えます。
向く例:調査役が集め、作成役がまとめ、レビュー役が確認する
時刻やイベントをきっかけに動きます。人が画面の前にいないため、最初は公開ではなく下書き・通知・ログまでに止める設計が安全です。
向く例:週1回ニュース候補を選び、下書きを1件保存する
迷ったら、より自動的な型を選ぶのではなく、判断の曖昧さがある場所だけを一段ずつ任せます。
まずは通常のスクリプトや定期実行。AIに判断させる必要はありません。
ワークフロー型から始めます。入力・出力・停止条件を固定します。
単一エージェント型を検討します。最大ステップ数と使える道具を絞ります。
複数エージェント型。ただし、最初は一つのエージェントで足りない理由を確認してから進みます。
定期・バックグラウンド型。公開・送信ではなく、下書きとログを完成条件にします。
種類を選ぶことは、権限を無制限に渡すことではありません。どの型でも、読む・作る・送るを分けます。
公開情報、指定したファイル、ログの読み取り。対象と範囲を先に伝えます。
下書き、候補リスト、変更案。出力先と件数を固定し、人が内容を読みます。
メール・SNS投稿・削除・課金・本番公開。宛先、対象、本文、金額を確認してから承認します。
型の名前だけでは足りません。目的、使える道具、保存場所、止まる条件を一緒に書きます。
目的:公開情報から候補を3件集め、条件に合うものを1件選んで下書きにする。
型:ワークフロー型。検索と選別だけをAIに任せる。
使ってよいもの:指定した公開API、作業フォルダへの読み書き。
手順:候補を取得 → 条件を表示 → 選んだ理由を説明 → ./draft/ に保存。
禁止:メール送信、SNS投稿、削除、課金、本番公開。
停止条件:候補がない、条件が曖昧、権限が必要、エラーが2回続く場合は止めて報告する。「何でも任せる」から始めず、読み取り→下書き→人の承認の順に広げます。これができてから、必要なら単一エージェントや複数エージェントを検討します。