去年の10月、私はClaudeにかなり退屈なタスクを与えた：「WordPress REST APIラッパーをPHPでスキャフォルドし、PHPUnitテストを書き、実行し、失敗したものを修正しろ。」ローカルのClaude tool-useセットアップ経由でターミナルへのアクセスを与えて、紅茶を入れに行った。12分後に戻ってきた。テストは全て成功し、94%のカバレッジを持つ動作するラッパーがあり、Claudeが簡潔な指示では言及していなかったエッジケースを捕捉した小さなインラインコメントがあった。Bermondseyの台所に立ったまま、本気で不安になった。
これがエージェンティック開発だ。自動補完ではなく、より賢いStack Overflowでもない。目標について推論し、次のアクションを選択し、実行し、結果を観察し、完了するまでループするモデル。そしてそれは過去9年間でほぼ他のどの技術よりも早く、Seahawk Mediaでのプロジェクト運営方法を変えている。
「エージェンティック」が実際に意味すること（そして意味しないこと）
正確にしておこう。この言葉は緩く使われているから。エージェンティックなAIループには3つのものがある：目標、ツールのセット、そして今何が起きたかに基づいて次に何をするかを決める能力。モデルは単にテキストを生成しているのではない。作用し、観察し、再計画している。
それが魔法ではないということだ。モデルは依然として関数シグネチャを幻覚できる。同じ誤った修正を7回繰り返して自分自身をコーナーにループできる。ステップ1で目標を誤解して、10ステップ間違った方向で自信をもって構築できる。私はこれらすべてを見てきた。一度、Reactダッシュボードプロジェクトで、Claudeは実は欠落したawaitだった問題を解決するために、ますます凝ったnullチェックを追加することに20分ほど費やした。その一件は私の失敗だ、初期の仕様が曖昧だった。
実務家にとって重要な区別は以下の通りだ：狭く定義されたエージェントタスクは、オープンエンドなタスクに勝る。「アラビア語、日本語、絵文字に対応したスラグサニタイゼーション関数を書いてテストする」は優れたエージェントタスクだ。「SaaS を構築してくれ」はそうではない。スコープを厳密に保つか、さもなければ間違った方向性の見直しに費やす時間は、単にコードを書くだけで済む時間よりも多くなるだろう。
私が実際に使用しているスタック
ツールの選択がここでは極めて重要だ。適切なスキャフォルディングがなければ、「エージェント的な Claude」は単なるチャットウィンドウに過ぎない。
Seahawk での現在のセットアップは以下の通り：
- [Claude API](https://www.anthropic.com/api)（ツール使用機能付き、特に computer_use ベータと カスタム bash/ファイルシステムツール）
- IDE レイヤーとしての Cursor。バックエンドモデルとして Claude 3.5 Sonnet を設定
- プロジェクトに応じて pytest / PHPUnit / Jest を使用。Claude が確定的なシグナルをループさせるために必要だからだ。テスト出力がなければ、盲目的に飛んでいるようなものだ。
- プロジェクト構造が何であるか、コーディング標準が何であるかを Claude に伝える短いシステムプロンプト。そして重要なことに、指定されたディレクトリ外に新しいファイルを作成しようとしているなら、一旦止めて確認するよう指示すること。
この最後の制約は軽微に聞こえるかもしれない。だが違う。エージェント的なモデルはゴールに役立つと思えば、新しいモジュール全体をせっせとスキャフォルディングしてしまう。ファイルシステムへのガードレールは、何度も「これはどこから出てきたんだ？」という瞬間から私を救ってくれた。
私が使用しないもの：ほとんどの作業にマルチエージェントオーケストレーションフレームワークを使用しない。LangChain、AutoGen、CrewAI は本当に興味深いが、ソロ開発者または小規模エージェンシー向けの用途では、エージェント同士が会話するための設定のオーバーヘッドは通常、その価値がない。スコープの定まった Claude ループ 1 つが、スコープの定まらない 3 つのエージェントが互いに主張を張り合うより優れている。
ループ値のあるタスクの構造化方法
今年200回以上のエージェンティックセッションを重ねて、僕が落ち着いた方法がこれだ。モデルに4つの要素を含むタスク概要を与える：
- 目標。具体的で、テスト可能で、30ステップ未満で完了できるほど小さいもの
- 開始状態。存在するファイルは何か、既に合格しているテストは何か
- 成功条件。通常は「全テスト合格」か、生成すべき特定の関数シグネチャ
- 停止条件。「同じ修正を3回以上試みたら、停止して理由を説明する」
この4番目のが過小評価されている。これがないと、Claudeは無限ループに入ることがある。永遠ではないにしても、複雑な正規表現の問題で18回の試行を見たことがあり、それぞれ少しずつ異なり、すべて不正解で、一度も「確信がない」と言わない。明確に混乱を表出するよう促すことは、実はAnthropicのモデル仕様で不確実性へのアプローチという形で議論されているが、実際には、プロンプトで求める必要がある。
2022年、クライアントはレガシーMagentoインストールから14,000個の商品リストをWooCommerceに移行するという仕事をくれた。その当時Claudeはエージェンティックループをしていなかったから、僕たちは2週間かけて手作業で移行スクリプトを書いた。同じ仕事を今日やるなら？Magentoのデータベーススキーマへの読み取りアクセスとステージング用WooCommerceインスタンスへの書き込みアクセスを持つ、タイトな仕様をClaudeに与えて実行させる。実際のところ2日で完了すると思う。それが差分だ。
Claudeが意外に優れている領域
既存コードのリファクタリング
ここが最も印象的だった点です。メチャクチャな400行のクラスを与えて、単一責任の原則に向けたリファクタリングをするよう指示し、チェックポイントとして独自のユニットテストを実行させます。ファイル全体を通じてコンテキストを保持する能力は予想以上で、パスしているテストを壊さないことに本当に気をつけています。出力が常に私が選択する設計とは限りませんが、通常は正当性があります。
自分で書いていないコードのテスト作成
Seahawkは多くのサイト監査と復旧作業を行います。テストがゼロで元の開発者が誰もいないコードベースを継承することはよくあります。継承したコードに何も手を加える前に、エージェント型のClaudeを使ってテストスイートを書くようになりました。ソースコードを読み、関数名とコメントから意図を推測し、テストを書き、実行し、予期しない失敗があれば調整します。先月、カスタムWooCommerceオーダーハンドラーにある、おそらく2年前からあったサイレントデータ破損バグを発見しました。誰も知りませんでした。
ボイラープレートコードの処理
RESTエンドポイントのスキャフォルディング、CRUD マイグレーション、管理画面フォーム。有能な開発者なら午後で完了する退屈な作業で、誰も楽しくありません。Claudeはここで高速で一貫性があり、実はボイラープレートに求められるのは一貫性で、創意工夫ではなく、疲れることもなく、既存コードとパターンマッチングして拡張するだけです。
うまくいかない場面
正直に言って、失敗は教訓になります。最もよく遭遇したものをいくつか挙げます。
- 大規模コードベースでのコンテキストウィンドウオーバーフロー。Claude 3.5 Sonnetは200k トークンのコンテキストウィンドウを持ちますが、40ファイルのフルWP プラグインをフィードするまで、それが非常に大きく思えます。セッションの早期に見たものを忘れ始めます。解決策：明示的なチェックポイント付きで、ジョブを小さなループに分割します。
- 自信を持つべきではないことに対する信頼。Claudeはデータベースクエリを修正し、テストを実行すると合格しますが、クエリはインデックスフレンドリーなWHERE句をサブクエリに変更したため、現在わずかに効率が低下しています。述べられた問題は解決しましたが、述べられていない問題を作成しました。コードレビューはまだ重要です。
- ツールパーミッションの拡大。bashアクセスを与えて制限しなければ、要求していないパッケージに対して npm install を実行したり、さらに悪いことに、認可していないネットワークリクエストを行ったりします。これは悪意ではなく、モデルが有益だと思っていることをしているだけです。何か奇妙なことが起こった後ではなく、始める前にツールパーミッションを設定してください。
セキュリティに関する注記：本番データに接続されているものに対してエージェントループを実行している場合は、Anthropic自身のツール使用安全性に関するガイダンスをお読みください。長くはありませんが、悪い結果を避けるのに役立ちます。
エージェント的動作とチャット的動作のプロンプティング
プロンプティングモデルは異なり、これは多くの人を戸惑わせます。チャットコンテキストではあなたは会話的で、反復的で、往復的です。エージェントコンテキストでは、初期プロンプトは仕様書です。あなたはタスク途中で説明のために側にいることはありません。
エージェントプロンプトを機能させるもの：
- 制約は最後ではなく最初に述べてください。ほとんどの人はそれらを隠します。
- それに何をすべきでないかを告げてください。「/src/utils の外のファイルを変更しないでください」は、十行の肯定的な指示よりも有用です。
- それに逃げ道を与えてください。「進めることがデータベーススキーマの変更を必要とする判断ポイントに到達した場合は、停止して理由の要約を書いてください」
- テストランナーコマンドを明示的に参照してください。「すべての変更後に ./vendor/bin/phpunit tests/ を実行し、その出力を次のステップの指針として使用してください」
フレーミング変更は：あなたは非常に有能だが質問できないコントラクターへの指示書を書いています。ですからそのように書いてください。
自律性ダイアル：どの程度実行させるか
これは他のエージェンシーオーナーから最も多くもらう質問だ。AIに任せっぱなしにするか、それとも監視し続けるか、という話だ。
1年間やってみた後の答えはこうだ：完全に可逆性にかかっている。読み取り専用のリサーチ、テスト作成、新しいディレクトリへのスカフォールディングなら、実行させる。ただし、本番データベースに触れるもの、パッケージマニフェストを変更するもの、外部APIと連携するものは、数ステップごとに確認するか、少なくとも実行前に計画を確認すべきだ。
ReActプロンプティングパターン（Reason + Act、2022年のYao et al.論文から）はここで理解する価値がある。本質的には、Claudeがツールを与えられたときに内部で行っていることだ：何をするかについて声に出して考え、実行し、結果を読み、再び考える。その推論を可視化し、Claudeに各アクション前に計画を出力させることで、ループを分断することなく自然なレビューポイントが生まれる。
Claudeのステップバイステップの推論出力を、ジュニア開発者のプルリクエストと同じように扱い始めた。ざっと目を通す。何か変なら介入する。妥当そうなら先に進めさせる。このメンタルモデルが自分にはうまく機能している。
よくある質問
エージェント化したClaudeは実際に本番環境の顧客案件に対応できるのか？
特定の限定的なタスクで本番環境以外であれば、そうだ、絶対にできる。プロジェクトのスカフォールディング、リファクタリング、テスト作成フェーズで定期的に使っている。本番の顧客データベースや外部決済APIに触れるものについては、実行ステップごとに必ず人間をループに入れている。モデルは有能だ。リスクはモデル自体ではなく、間違いの影響範囲にある。
エージェント化したClaudeとCursorやGitHub Copilotを使うのとどう違うのか？
CursorとCopilotはインラインコード提案とチャットインターフェース。お前が入力したものに反応する。エージェント化したClaudeは目標を与えられると、ターミナル、ファイルシステム、ウェブブラウザのようなツールを使い、複数ステップの計画を自動で実行する。オートコンプリートエンジンと、10分間は監視なしで実行でき、完了したタスクを持って戻ってこられるプロセスの違いだ。
これを使うのにコードを書けないといけないのか？
コンテキストが十分にあれば、一貫性のあるスペックを書き、出力を批判的にレビューできます。diffを読んで、その変更が理にかなっているかどうかを判断できなければ、うまくいきません。エージェンティックAIは能力を増幅します。基礎は置き換えません。
エージェンティックループにはどのClaudeモデルを使うべきですか？
Claude 3.5 Sonnetが私の現在のデフォルトです。推論品質と速度のバランスが取れており、30ステップのループで1トークンあたりの料金を払うときに重要です。Claude 3 Opusはより複雑な推論タスクに優れていますが、遅く、より高価です。大規模ジョブの初期計画ステップに使用し、その後Sonnetに実行をハンドオフします。
---
何度も戻ってくるのは、エージェンティック開発は本当にはAIが開発者を置き換えることについてではないということです。それは開発者の時間の価値を変えることについてです。昨年10月にあのPHPラッパーを書くのに費やさなかった12分間、私は設計思想について考えていました。その取引なら何度でも引き受けます。