メインコンテンツにスキップ

パート4: 作業の実行

ルールファイル、エンジニアリングされたコンテキスト、そして検証の仕組みが整いました。いよいよ実際に作業を行います。うまくいくかどうかを決める2つの問いは：どのモードにいるか、そしてどの種類のエージェントがタスクに合っているか、です。

2つのモード：コンダクターとオーケストレーター​

ほとんどの開発者は一日を通じて2つのモードを行き来しています。それぞれ異なるスキルを要求し、タスクに対して間違ったモードを使うことはフラストレーションのよくある原因です。

コンダクターモードはリアルタイム、ハンズオンです。エディタの中にいて、コードが現れるのを見ながら、プロンプトと修正で操作し、細かいコントロールを維持します。変更がなされるたびにそれを理解します。

  • 最適な用途：複雑なロジック、難しいデバッグ、不慣れなコードベース — 各ステップを理解する必要があるところ。
  • リスク：すべてのキーストロークを指示すると、あなた自身がボトルネックになり、スピードアップが消えてしまう。

オーケストレーターモードは非同期で高レベルです。ゴールを定義し、エージェントに渡し、キーストロークではなく成果をレビューします。エージェントはバックグラウンドで、並行して、コードベースの異なる部分で実行される場合があります。

  • 最適な用途：仕様が明確な作業 — バグ修正、マイグレーション、テスト生成、確立されたパターンに沿ったフィーチャー。
  • 注意点：より少ない規律ではなく、より多くの規律が前もって必要です。委任する前に正確な仕様を書かなければなりません。成果は最初のタスクではなく、2番目のタスクで現れます。

オーケストレーターモードは、構文の流暢さとは異なるスキルセットを必要とします：

  • 仕様 — エージェントが推測なしに実行できる程度に正確にタスクを定義する。
  • 分解 — 大きな作業をエージェントサイズの単位に分割する。
  • 評価 — アウトプットの品質を素早く判断する。
  • システム設計 — エージェントを生産的に保つ制約とフィードバックループを構築する。

日々の業務でエージェントが活躍する3つの場所​

同じ状況を別の角度から見ると、エージェントは3つの場所に現れます。ほとんどの人は3つすべてを使います。

  • エディタの中 — インライン補完とインプレースチャット、コードベース全体の認識とともに。ここではフローに留まります。（Copilot、Cursor、Windsurf、JetBrains AI。）
  • ターミナルの中 — エージェントを起動し、平易な言語でゴールを渡し、ファイルをまたいで作業させ、ツールとテストを実行し、結果に反応させます。ここで本格的なハンズオンの作業が行われます。（Claude Code、Codex CLI など。）
  • バックグラウンド — エージェントはサンドボックス内で自律的に動作し、場合によっては何時間も動き続け、後でレビューするためのプルリクエストを返します。（Jules、Copilot エージェントモード、Cursor バックグラウンドエージェント。）

マッピングは一度把握すれば直感的です：エディタエージェントは書いている間に合い、ターミナルエージェントは複数ファイルの探索と実行して対応に合い、バックグラウンドエージェントはパラグラフで説明して離れられるものに合います。正しい出発点は、最も自律性を主張するツールではなく、タスクです。

サンドボックス内で実行する​

エージェントがコードを実行する際 — テストの実行、修正の試み、ファイルの読み取り — それは定義された限定的なツールセットとアクセス権を持つ分離されたサンドボックス内で行うべきです。これが自律的な「考える→行動する→観察する」ループを安全にするものです。エージェントは触れるべきでないものに触れることなく、試みて失敗することができます。

80%問題（うまくいかない場所）​

エージェントはフィーチャーの約80%を素早く生成します。残りの20% — エッジケース、エラー処理、統合ポイント、微妙な正確性 — は、モデルが通常持っていない深いコンテキストを必要とします。そして、これこそ本番障害が潜む場所です。

危険性は変わりました。初期のAIエラーは明らかな構文ミスでした。今日のエラーは概念的なものです：ビジネスロジックに関する誤った仮定、見逃したエッジケース、静かに保守負債を積み重ねるアーキテクチャ上の選択。これらを捕まえることが難しいのは、まさにコードが正しく見え、基本的なテストさえ通過する可能性があるからです。

具体的に：

# The agent's 80%: looks correct, passes the happy-path test
def apply_discount(price, percent):
    return price * (1 - percent / 100)

欠けている20%は、エージェントが尋ねることを知らなかったすべてのことです：percent が100を超えることはあるか？price は整数のセント値かそれともfloatか？どの通貨の丸め処理が適用されるか？100%の割引は許可されるべきか、それともそれは上流のバグを示すシグナルか？これらはいずれもコードに見えるものではなく、あなたが保持しているビジネスルールであり、モデルは持っていません。

うまくやっている開発者たちは、すべてを受け入れることでより速く進もうとはしません。仕様が明確な80%にエージェントを使い、判断が必要な20%に自分の注意を使います。

自分のワークフローをセットアップする​

  • タスクの前に、意識的にコンダクターかオーケストレーターかを選ぶ — そして委任すべきだった作業をコンダクティングしているときに気づく。
  • エージェントの配置場所をタスクに合わせる：フロー内にはエディタ、複数ファイルにはターミナル、離れられるものにはバックグラウンド。
  • コードの実行がスコープされたアクセス権のサンドボックス内で行われることを確認する。
  • すべてのフィーチャーについて、20% — エッジケースとビジネスルール — を書き留め、テストが通ってもそれらの行は自分でレビューする。