去年の10月、私はClaudeにかなり退屈なタスクを与えた：「WordPress REST APIラッパーをPHPでスキャフォルドし、PHPUnitテストを書き、実行し、失敗したものを修正しろ。」ローカルのClaude tool-useセットアップ経由でターミナルへのアクセスを与えて、紅茶を入れに行った。12分後に戻ってきた。テストは全て成功し、94%のカバレッジを持つ動作するラッパーがあり、Claudeが簡潔な指示では言及していなかったエッジケースを捕捉した小さなインラインコメントがあった。Bermondseyの台所に立ったまま、本気で不安になった。Claude tool-use setup and walked away to make tea. Came back twelve minutes later. Tests were green. I had a working wrapper with 94% coverage and a small inline comment where Claude had caught an edge case I hadn't mentioned in the brief. I stood there in my kitchen in Bermondsey genuinely unsettled.
これがエージェンティック開発だ。自動補完ではなく、より賢いStack Overflowでもない。目標について推論し、次のアクションを選択し、実行し、結果を観察し、完了するまでループするモデル。そしてそれは過去9年間でほぼ他のどの技術よりも早く、Seahawk Mediaでのプロジェクト運営方法を変えている。
「エージェンティック」が実際に意味すること（そして意味しないこと）
正確にしておこう。この言葉は緩く使われているから。エージェンティックなAIループには3つのものがある：目標、ツールのセット、そして今何が起きたかに基づいて次に何をするかを決める能力。モデルは単にテキストを生成しているのではない。作用し、観察し、再計画している。
それが魔法ではないということだ。モデルは依然として関数シグネチャを幻覚できる。同じ誤った修正を7回繰り返して自分自身をコーナーにループできる。ステップ1で目標を誤解して、10ステップ間違った方向で自信をもって構築できる。私はこれらすべてを見てきた。一度、Reactダッシュボードプロジェクトで、Claudeは実は欠落したawaitだった問題を解決するために、ますます凝ったnullチェックを追加することに20分ほど費やした。その一件は私の失敗だ、初期の仕様が曖昧だった。not is magic. The model can still hallucinate a function signature. It can loop itself into a corner doing the same wrong fix seven times. It can misunderstand your goal at step one and build confidently in the wrong direction for ten steps. I've seen all of these. Once, on a React dashboard project, Claude spent about twenty minutes adding increasingly baroque null checks to solve a problem that was actually a missing await. That one was my fault, I gave it a vague initial spec.
実務家にとって重要な区別は以下の通りだ：狭く定義されたエージェントタスクは、オープンエンドなタスクに勝る。「アラビア語、日本語、絵文字に対応したスラグサニタイゼーション関数を書いてテストする」は優れたエージェントタスクだ。「SaaS を構築してくれ」はそうではない。スコープを厳密に保つか、さもなければ間違った方向性の見直しに費やす時間は、単にコードを書くだけで済む時間よりも多くなるだろう。narrow agentic tasks beat open-ended ones. "Write and test a slug sanitisation function that handles Arabic, Japanese, and emoji" is a great agentic task. "Build me a SaaS" is not. Scope it tight, or you'll spend more time reviewing wrong turns than you would have spent just writing the code.
私が実際に使用しているスタック
ツールの選択がここでは極めて重要だ。適切なスキャフォルディングがなければ、「エージェント的な Claude」は単なるチャットウィンドウに過ぎない。
Seahawk での現在のセットアップは以下の通り：
- [Claude API](https://www.anthropic.com/api)（ツール使用機能付き、特に computer_use ベータと カスタム bash/ファイルシステムツール）, specifically the
computer_usebeta and custom bash/filesystem tools - IDE レイヤーとしての Cursor。バックエンドモデルとして Claude 3.5 Sonnet を設定 as the IDE layer, with Claude 3.5 Sonnet set as the backend model
- プロジェクトに応じて pytest / PHPUnit / Jest を使用。Claude が確定的なシグナルをループさせるために必要だからだ。テスト出力がなければ、盲目的に飛んでいるようなものだ。 depending on the project, because Claude needs a deterministic signal to loop on. Without test output, it's flying blind.
- プロジェクト構造が何であるか、コーディング標準が何であるかを Claude に伝える短いシステムプロンプト。そして重要なことに、指定されたディレクトリ外に新しいファイルを作成しようとしているなら、一旦止めて確認するよう指示すること。 that tells Claude what the project structure is, what the coding standards are, and, this is important, to stop and ask if it's about to create a new file outside the specified directory.
この最後の制約は軽微に聞こえるかもしれない。だが違う。エージェント的なモデルはゴールに役立つと思えば、新しいモジュール全体をせっせとスキャフォルディングしてしまう。ファイルシステムへのガードレールは、何度も「これはどこから出てきたんだ？」という瞬間から私を救ってくれた。
私が使用しないもの：ほとんどの作業にマルチエージェントオーケストレーションフレームワークを使用しない。LangChain、AutoGen、CrewAI は本当に興味深いが、ソロ開発者または小規模エージェンシー向けの用途では、エージェント同士が会話するための設定のオーバーヘッドは通常、その価値がない。スコープの定まった Claude ループ 1 つが、スコープの定まらない 3 つのエージェントが互いに主張を張り合うより優れている。
ループ値のあるタスクの構造化方法
今年200回以上のエージェンティックセッションを重ねて、僕が落ち着いた方法がこれだ。モデルに4つの要素を含むタスク概要を与える：
- 目標。具体的で、テスト可能で、30ステップ未満で完了できるほど小さいもの, specific, testable, small enough to finish in under 30 steps
- 開始状態。存在するファイルは何か、既に合格しているテストは何か, what files exist, what tests already pass
- 成功条件。通常は「全テスト合格」か、生成すべき特定の関数シグネチャ, usually "all tests green" or a specific function signature it must produce
- 停止条件。「同じ修正を3回以上試みたら、停止して理由を説明する」, "if you've tried the same fix more than three times, stop and explain why you're stuck"
この4番目のが過小評価されている。これがないと、Claudeは無限ループに入ることがある。永遠ではないにしても、複雑な正規表現の問題で18回の試行を見たことがあり、それぞれ少しずつ異なり、すべて不正解で、一度も「確信がない」と言わない。明確に混乱を表出するよう促すことは、実はAnthropicのモデル仕様で不確実性へのアプローチという形で議論されているが、実際には、プロンプトで求める必要がある。Anthropic model spec discusses in terms of the model's approach to uncertainty, but in practice, you still need to prompt for it.
2022年、クライアントはレガシーMagentoインストールから14,000個の商品リストをWooCommerceに移行するという仕事をくれた。その当時Claudeはエージェンティックループをしていなかったから、僕たちは2週間かけて手作業で移行スクリプトを書いた。同じ仕事を今日やるなら？Magentoのデータベーススキーマへの読み取りアクセスとステージング用WooCommerceインスタンスへの書き込みアクセスを持つ、タイトな仕様をClaudeに与えて実行させる。実際のところ2日で完了すると思う。それが差分だ。
Claudeが意外に優れている領域
既存コードのリファクタリング
ここが最も印象的だった点です。メチャクチャな400行のクラスを与えて、単一責任の原則に向けたリファクタリングをするよう指示し、チェックポイントとして独自のユニットテストを実行させます。ファイル全体を通じてコンテキストを保持する能力は予想以上で、パスしているテストを壊さないことに本当に気をつけています。出力が常に私が選択する設計とは限りませんが、通常は正当性があります。I would choose, but it's usually defensible.
自分で書いていないコードのテスト作成
Seahawkは多くのサイト監査と復旧作業を行います。テストがゼロで元の開発者が誰もいないコードベースを継承することはよくあります。継承したコードに何も手を加える前に、エージェント型のClaudeを使ってテストスイートを書くようになりました。ソースコードを読み、関数名とコメントから意図を推測し、テストを書き、実行し、予期しない失敗があれば調整します。先月、カスタムWooCommerceオーダーハンドラーにある、おそらく2年前からあったサイレントデータ破損バグを発見しました。誰も知りませんでした。
ボイラープレートコードの処理
RESTエンドポイントのスキャフォルディング、CRUD マイグレーション、管理画面フォーム。有能な開発者なら午後で完了する退屈な作業で、誰も楽しくありません。Claudeはここで高速で一貫性があり、実はボイラープレートに求められるのは一貫性で、創意工夫ではなく、疲れることもなく、既存コードとパターンマッチングして拡張するだけです。
うまくいかない場面
正直に言って、失敗は教訓になります。最もよく遭遇したものをいくつか挙げます。
- 大規模コードベースでのコンテキストウィンドウオーバーフロー。Claude 3.5 Sonnetは200k トークンのコンテキストウィンドウを持ちますが、40ファイルのフルWP プラグインをフィードするまで、それが非常に大きく思えます。セッションの早期に見たものを忘れ始めます。解決策：明示的なチェックポイント付きで、ジョブを小さなループに分割します。 Claude 3.5 Sonnet has a 200k token context window, which sounds enormous until you're feeding it a full WP plugin with 40 files. It starts forgetting things it saw early in the session. Solution: break the job into smaller loops with explicit checkpoints.
- 自信を持つべきではないことに対する信頼。Claudeはデータベースクエリを修正し、テストを実行すると合格しますが、クエリはインデックスフレンドリーなWHERE句をサブクエリに変更したため、現在わずかに効率が低下しています。述べられた問題は解決しましたが、述べられていない問題を作成しました。コードレビューはまだ重要です。 Claude will fix a database query, run the test, it passes, and report success, but the query is now subtly less efficient because it swapped an index-friendly
WHEREclause for a subquery. It solved the stated problem and created an unstated one. Code review still matters. - ツールパーミッションの拡大。bashアクセスを与えて制限しなければ、要求していないパッケージに対して npm install を実行したり、さらに悪いことに、認可していないネットワークリクエストを行ったりします。これは悪意ではなく、モデルが有益だと思っていることをしているだけです。何か奇妙なことが起こった後ではなく、始める前にツールパーミッションを設定してください。 If you give it bash access and don't constrain it, it will run
npm installfor packages you didn't ask for, or worse, make a network request you didn't sanction. This isn't malicious, it's the model doing what seems helpful. Set your tool permissions before you start, not after something weird happens.
セキュリティに関する注記：本番データに接続されているものに対してエージェントループを実行している場合は、Anthropic自身のツール使用安全性に関するガイダンスをお読みください。長くはありませんが、悪い結果を避けるのに役立ちます。guidance on tool-use safety. It's not long, and it will save you a bad day.
エージェント的動作とチャット的動作のプロンプティング
プロンプティングモデルは異なり、これは多くの人を戸惑わせます。チャットコンテキストではあなたは会話的で、反復的で、往復的です。エージェントコンテキストでは、初期プロンプトは仕様書です。あなたはタスク途中で説明のために側にいることはありません。
エージェントプロンプトを機能させるもの：
- 制約は最後ではなく最初に述べてください。ほとんどの人はそれらを隠します。
- それに何をすべきでないかを告げてください。「/src/utils の外のファイルを変更しないでください」は、十行の肯定的な指示よりも有用です。not to do. "Do not modify any file outside
/src/utils" is more useful than ten lines of positive instructions. - それに逃げ道を与えてください。「進めることがデータベーススキーマの変更を必要とする判断ポイントに到達した場合は、停止して理由の要約を書いてください」
- テストランナーコマンドを明示的に参照してください。「すべての変更後に ./vendor/bin/phpunit tests/ を実行し、その出力を次のステップの指針として使用してください」
./vendor/bin/phpunit tests/after every change and use the output to guide your next step."
フレーミング変更は：あなたは非常に有能だが質問できないコントラクターへの指示書を書いています。ですからそのように書いてください。
自律性ダイアル：どの程度実行させるか
これは他のエージェンシーオーナーから最も多くもらう質問だ。AIに任せっぱなしにするか、それとも監視し続けるか、という話だ。
1年間やってみた後の答えはこうだ：完全に可逆性にかかっている。読み取り専用のリサーチ、テスト作成、新しいディレクトリへのスカフォールディングなら、実行させる。ただし、本番データベースに触れるもの、パッケージマニフェストを変更するもの、外部APIと連携するものは、数ステップごとに確認するか、少なくとも実行前に計画を確認すべきだ。
ReActプロンプティングパターン（Reason + Act、2022年のYao et al.論文から）はここで理解する価値がある。本質的には、Claudeがツールを与えられたときに内部で行っていることだ：何をするかについて声に出して考え、実行し、結果を読み、再び考える。その推論を可視化し、Claudeに各アクション前に計画を出力させることで、ループを分断することなく自然なレビューポイントが生まれる。ReAct prompting pattern (Reason + Act, from the 2022 Yao et al. paper) is worth understanding here. It's essentially what Claude does internally when you give it tools: it thinks out loud about what to do, does it, reads the result, thinks again. Making that reasoning visible, asking Claude to print its plan before each action, gives you a natural review point without breaking the loop.
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分間、私は設計思想について考えていました。その取引なら何度でも引き受けます。