しんたろーのITアカデミー
AI活用Tips

なぜAI丸投げは終わるのか。Claude Code開発を3コマンドに分け人間が承認する1人SaaSの最新運用術

なぜAI丸投げは終わるのか。Claude Code開発を3コマンドに分け人間が承認する1人SaaSの最新運用術
しんたろーしんたろー
11分で読めます
この記事の内容(目次)

SNS運用を自動化しませんか?

ThreadPostなら、投稿作成・画像生成・スケジュール管理までAIがサポート。

無料で始める

冒頭フック

AIに「よしなに作って」と丸投げする時代は終わった。

ある海外のAIチームが、AIモデルを一切変更せず、外側の環境を整備しただけでベンチマークスコアを52.8%から66.5%へと劇的に引き上げた。

天才的なプロンプトを書くスキルはもう古い。

これからの開発者に必要なのは、AIをどう動かし、どこで人間が手綱を握るかを設計する力だ。

AIエージェントの自律性が高まるほど、皮肉なことに人間の「承認」が最大のボトルネックになる。

ニュースの概要

海外の開発現場では、AIの能力を引き出すためのアプローチが根本から変わりつつある。

単一の強力なAIにすべてを任せるのではなく、AIを取り巻くシステム全体を設計する手法が主流だ。

この環境設計は、大きく3つのレイヤーに分けられる。

AIに何をすべきか教えるガイド層、どう動かすかを定義する実行層、そして結果を計測する監視層だ。

これらが揃って初めて、AIエージェントは安定して稼働する。

プロンプトエンジニアリングの時代は終わりを告げた。

個別の指示文を最適化するフェーズから、コンテキスト全体を管理するフェーズへ移行した。

そして現在は、エージェントが動く外側の仕組みを構築する「ハーネスエンジニアリング」へと進化している。

ある開発チームは、この環境設計を徹底することで、わずか5ヶ月100万行のコードを生成した。

人間が手書きしたソースコードはゼロだ。

これを可能にしたのは、依存関係の制約やレイヤー違反の自動検出など、AIの外側に構築された堅牢な仕組みだ。

AIに与える指示書のあり方も劇的に変化している。

海外の最新の研究では、一般的なコーディング規約など、AIが自力で推論できる情報を指示書に書くと、かえって性能が落ちることが判明している。

不要な情報はAIにとってただのノイズになる。

推奨される指示書の長さは200行以内だ。

AIが自力で発見できないプロジェクト特有のディレクトリ構成や独自ルールのみを記述する。

必要な情報は、AIに「見つけ方」だけを教え、必要なタイミングでアクセスさせる。

また、開発プロセス全体を単一の指示で動かすのではなく、複数のステップに分割する手法が確立されている。

要件定義、タスク分解、実装といった具合に、明確にフェーズを分ける。

そして最も重要なのが、クリティカルなポイントで必ず人間の承認を挟むことだ。

AIが勝手に暴走するのを防ぐため、テスト計画の立案などの重要フェーズは、人間が許可を出さないと次に進めない設計になっている。

完全に自律させるのではなく、人間をループの中に組み込む。

これが、最新のAI開発における絶対的なベストプラクティスだ。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。
AIが安定稼働するための「3つの環境レイヤー」
AIが安定稼働するための「3つの環境レイヤー」

開発者目線の解説

この一連の流れは、1人SaaSを開発する僕にとっても非常に納得感がある。

AIエージェントに「テスト駆動で開発して、レビューして、プルリクを作って」と一度に指示しても、途中で必ず破綻する。

AIは指示を忘れ、独自の解釈でコードを書き始め、最終的にレビューすら放棄する。

これはAIの頭が悪いのではなく、人間のタスクの渡し方が雑すぎるからだ。

解決策は、開発プロセスを3つのコマンドに分割することだ。

  • 自然言語の要件から機能のイシューを作成するフェーズ
  • そのイシューをアーキテクチャのレイヤーごとに細かいタスクに分解するフェーズ
  • 小さなタスク単位で実装コマンドを走らせるフェーズ

タスクが小さければ小さいほど、AIはコンテキストを失わずに正確な仕事をする。

現在、AIのコンテキストウィンドウは100万トークンに達している。

しかし、だからといって巨大なタスクを丸投げしていい理由にはならない。

ドメイン駆動設計のようなレイヤーに基づくタスク分解は、AI開発と非常に相性がいい。

レイヤーごとに区切ることで、AIが触るファイルが限定される。

無駄な探索や変更が減り、エラーの確率が劇的に下がる。

しんたろーしんたろー:
1機能1イシューの巨大な粒度でClaude Codeに丸投げしてた頃は、マジで地獄だった。
コードベース全体を書き換えられて、元に戻すだけで半日溶けるとかザラ。
タスクを細かく割るようになってからは、AIの挙動がめちゃくちゃ安定してビビる。

さらに重要なのが、テスト計画の分離だ。

テストコードの作成までAIに一任するのは危険極まりない。

テストケースは仕様そのものであり、そこが間違っていれば生成されるコードもすべてゴミになる。

だからこそ、実装に入る前に「テスト計画の立案」だけをAIにやらせる。

AIが出してきたテスト計画を人間が確認し、承認するか修正を指示する。

人間の許可が下りて初めて、AIは実際のコーディングを開始する。

この「人間の介入」をシステムに組み込むことが、品質を担保する唯一の手段だ。

AIの自律性をあえて制限し、要所で人間が手綱を握る。

完全に自動化されたパイプラインよりも、承認ゲートを設けたパイプラインの方が最終的な生産性は高くなる。

しんたろーしんたろー:
テストケースの承認フローを挟むのは、控えめに言って天才の所業だと思う。
うちの構成でも、AIが勝手に書いたテストが通るように実装を歪める現象が起きてた。
人間が仕様を握るっていう大原則は、AI時代でも絶対に変えちゃダメだな。

指示書の書き方も根本から見直す必要がある。

AIに「クリーンアーキテクチャを守れ」「変数名はスネークケースで」などと長々と書くのは逆効果だ。

そんなものは一般的な言語モデルなら言われなくても知っている。

推論可能な情報を書き連ねることは、AIにとってただのノイズになる。

指示書には、AIが推論できない情報だけを厳選して書く。

独自のコマンド、特殊なディレクトリ構成、特定のライブラリのバージョン制約などだ。

200行以内に収めるのがベストプラクティスとされている。

情報を削れば削るほど、AIは本当に重要なルールに集中できるようになる。

AIにすべてを教えようとするのは、開発者の自己満足に過ぎない。

開発プロセスを3フェーズに分割するアプローチ
開発プロセスを3フェーズに分割するアプローチ

ここまで読んだあなたに

今なら無料で全機能をお試しいただけます。設定後はAIが投稿案を毎日生成。確認して選ぶだけ。

無料で始める

実務への影響

で、僕らの開発にどう影響するのか。

まず、AIにどこまで任せるかをプロダクトの領域ごとに明確に切り分ける必要がある。

すべての機能を同じレベルでAIに任せるのは完全に悪手だ。

決済処理のような致命的な領域と、管理画面のUI修正では、リスクの桁が違う。

ディレクトリやファイルパスのパターンで、AIの権限を分岐させる仕組みが必須になる。

  • クリティカルな領域の変更が含まれる場合は、人間のレビューと承認を強制する
  • 影響範囲が限定的な領域はフルオートでマージまで進める
  • 歴史の長いレガシーコードには、AIの適用範囲を極力絞る

この切り分けをCI/CDのパイプラインに組み込むことが、これからのシニアエンジニアの仕事になる。

そして、もう一つ深刻な問題が発生する。

AIの自律性が上がり、複数のエージェントが同時に動くようになると「今、誰が何をしているか」が全く分からなくなる。

AIが人間の承認待ちで止まっているのに、人間がそれに気づかず放置してしまう。

結果として、人間が開発パイプラインの最大のボトルネックになる。

これを防ぐためには、エージェントの稼働状態を可視化するダッシュボードが必要だ。

しんたろーしんたろー:
複数のエージェントをバックグラウンドで走らせると、マジで迷子になる。
ターミナルのタブを一個ずつ確認して「あ、こいつ許可待ちじゃん」って気づくの遅れるんだよね。
監視用のダッシュボードがないと、人間がAIの足引っ張ることになるわ。

処理中なのか、完了したのか、それとも人間の許可を待っているのか。

数十体のエージェントが動く環境では、この監視システムがないと運用が回らない。

リアルタイムで状態を把握し、人間が即座に承認を出せる体制を整える。

チーム開発においては、技術的な設計よりも合意形成が厄介になる。

コードへのオーナーシップやAIへの不信感から、全自動化に抵抗を示すエンジニアは多い。

トップダウンで「全部AIでやれ」と押し通せば、必ず現場は荒れる。

いきなりすべてを自動化しようとするのは失敗の元だ。

まずは定型的なバグ修正やドキュメント生成など、リスクの低いところから小さく始める。

そこで「AIに任せても大丈夫だ」という実績とデータを積み上げる。

強制的にAIを導入するのではなく、データに基づいて徐々に委譲の範囲を広げていく。

人間がAIを信頼できる環境を作ること。

それが、最強の開発組織を作るための第一歩だ。

影響範囲に応じた承認フローの分岐
影響範囲に応じた承認フローの分岐

FAQ

Q1: Claude Codeで複数のエージェントを連携させるにはどうすればいいですか?

1つのラッパースクリプトから、単一の責務を持たせた複数のエージェントを順次呼び出す設計が有効だ。

要件定義、タスク分解、実装といった具合に、フェーズごとにAIの役割を完全に分ける。

複数のセッションを立ち上げて並行稼働させるアプローチもあるが、重要なのは各エージェントにすべてを任せないことだ。

責務を明確に分割し、パイプラインとして繋ぐのがベストプラクティスだ。

Q2: AIへの指示書には何をどこまで書くべきですか?

200行以内(最大でも300行)に抑えることが強く推奨される。

一般的なコーディング規約など、AIが自力で推論できる情報を書くとノイズになり性能が落ちる。

ディレクトリ構成や独自のビルドコマンドなど、AIが外部から発見できない情報だけに絞り込む。

詳細な規約は別ファイルに切り出し、必要なエージェントにのみ読み込ませるのが鉄則だ。

Q3: AIエージェントが勝手に間違った実装を進めてしまうのを防ぐには?

完全に自律させるのではなく、クリティカルなポイントで人間の承認を挟むことだ。

「テスト計画の立案」段階で人間の許可を必須にしたり、重要機能の変更には人間レビューを義務付ける。

AIが許可待ちで止まっている状態を監視するダッシュボードを導入することも重要だ。

人間がボトルネックにならないよう、承認プロセスをシステム的に可視化して管理する。

まとめ + CTA

AIエージェントの能力を引き出すのは、優秀な部下が働きやすい環境を整えるマネジメントと全く同じだ。

👉 ThreadPostでSNS運用を自動化する

ThreadPost — SNS投稿をAIが自動化

この記事が参考になったら、ThreadPostを試してみませんか?投稿作成・画像生成・スケジュール管理まで、AIがサポートします。

無料で始める

この記事をシェア

XはてブLINE
しんたろー

ThreadPost開発者・個人開発エンジニア

AI × SaaS個人開発者。Cursor / Claude Code を使った効率的開発、SNS自動化について実体験から発信。

人気の記事