Claude Codeの論文探索とDevinの並列処理を指揮する。1人SaaS開発の制約設計術

コードを書く作業は、もう人間の仕事じゃない。

AIが勝手に学術論文を読み込み、最適なアルゴリズムを提案する。

Devinが複数の子セッションを立ち上げ、並列でE2Eテストを回す。

これが今の開発現場のリアルだ。

僕たち開発者は「コードを書く人」から、AIという暴れ馬を乗りこなす「アーキテクト」に変わる。

プロンプトの微調整は通用しない。

AIの暴走を止める構造化された制約設計が求められる。

AIが自律的に論文を読み、複数エージェントを指揮する現実

最近のAI開発ツール周辺で、立て続けにヤバい動きが起きている。

単なる「コード生成」の枠を完全に超えた。

まず、AIが自律的に外部知識を取りに行く機能だ。

開発者が全く知らない専門領域でも、AIに「学術的なアプローチを調べろ」と指示する。

するとAIが勝手に論文や特許を検索し、複数の手法を比較検討する。

例えば音声の性別判定ロジックだ。

単純なピッチ（基本周波数）の判定では、興奮した男性の声を女性と誤認する。

ここでClaude CodeのResearchモードに調査させる。

フォルマント（声道の共鳴周波数）やMFCC（メル周波数ケプストラム係数）といった専門的な指標を組み合わせる手法を提示してくる。

人間は信号処理の専門家でなくても、AIの解説を読んで実装方針を立てられる。

知識のスタート地点がゼロじゃなくなる。

開発のスピードは根本から変わる。

次に、Devinによるマルチエージェントの並列処理だ。

1つのメインDevinセッションがコーディネーターになり、複数の子Devinを立ち上げる。

特別なコマンドは要らない。

タスクの規模をDevinが勝手に判断し、自動的にセッションを分割する。

子Devinはそれぞれ独立した仮想マシンで動く。

ターミナルも、ブラウザも、開発環境も完全に分離されている。

エージェント同士が環境を汚し合うことはない。

テストランナーも各セッション固有だ。

数十ページあるアプリのテスト。

アイコンライブラリの一括置き換え。

複数パッケージの脆弱性チェックを10セッション同時に走らせる。

人間がやれば数日かかる作業を、Devinがタスクを分割して並列で一気に終わらせる。

メインDevinが各セッションにタスクを振り分け、進捗を見守る。

競合があれば解決し、最終的に結果をまとめる。

人間のテックリードがやる仕事を、Devinが自動でこなす。

AIエージェントの使い方が「1対1の対話」から「チームとして束ねる」へ完全にシフトした。

一方で、AIモデル自体の内部構造も激変している。

最近のAIは、昔みたいに「もっともらしい嘘」を自信満々に語らなくなった。

少し慎重で、言うことを聞かないと感じる場面が増えた。

これはAIが劣化したわけじゃない。

モデルの中にアライメント、ポリシー、ルーター、モニターといった多層的な制御システムが組み込まれた結果だ。

僕らが入力したプロンプトは、そのまま言語モデルに届くわけじゃない。

システム指示や上位ルールが反映され、ポリシーに基づく判断が下される。

タスクに応じて適切な経路に振り分けられ、最終的にモニターが安全性や品質をチェックする。

表面的なプロンプトの言い回しを変えても、AIの挙動は根本的には変わらない。

内部のフィルターやルーターを通って、安全に整形されてから出力される。

AIは単なる次トークン予測器ではなく、複雑な多層制御システムになった。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

プロンプトエンジニアリングの終焉と制約設計の台頭

ここからが本題だ。

これらの動きから見えてくるのは、「プロンプトエンジニアリングの限界」だ。

AIに「いい感じにコードを書いて」と頼む手法は通用しない。

AIが賢くなり、多層的な制御システムを持つようになった。

曖昧な指示は内部のフィルターに弾かれる。

勝手に安全側に倒されて、凡庸なコードしか吐き出さなくなる。

しんたろー：
最近のモデル、マジで優等生ぶるから困る。
ちょっと複雑な処理頼むと安全側に倒して逃げようとするんだよな。
内部のルーターが勝手に経路選んでるのが透けて見える。
まぁ、僕のプロンプトが雑なだけなんだけど。

じゃあどうするか。

AIの内部を直接コントロールすることはできない。

ブラックボックスの中身をいじるのは不可能だ。

僕らができるのは、外側から意味の通路を狭めることだ。

これが「制約設計」の考え方だ。

例えば、未知のドメイン知識が必要な機能を作る時。

僕はClaude CodeのResearchモードを推している。

でも、調べさせてそのままコードを書かせることは絶対にしない。

そんなことをすれば、AIは文脈を見失って盛大にバグる。

複雑なロジックを自然言語のまま処理させようとするから破綻する。

まずはAIに論文や技術資料を調べさせる。

そして、採用するアルゴリズムの原理と構成を、厳密なフォーマットで出力させる。

JSONやMarkdownのテーブルなどだ。

これが構造化成果物だ。

自然言語の曖昧さを排除し、入力と出力の境界条件をカチカチに固める。

人間がその構造化されたデータを見て、方針として確定させる。

コードを書かせるのは、その方針がガチガチに固まってからだ。

AIに「このJSONの制約に完全に従って実装しろ」と命じる。

AIの自由度を奪う。

飛び立てる範囲を極限まで狭める。

そうすることで、AIの多層的な制御システムをすり抜け、狙った通りのコードを安定して出力させることができる。

内部の写像を直接変えるのではなく、入力集合と許容出力集合を狭めるアプローチだ。

しんたろー：
構造化成果物を挟むやり方、これ理にかなってる。
一発でコード書かせてバグ取りするより、仕様をガチガチに固める方がトータルで圧倒的に早い。
急がば回れってやつだ。

マルチエージェントの並列処理も同じだ。

複数のDevinを同時に走らせる時、一番怖いのはエージェント同士の暴走と干渉だ。

10セッションが勝手な解釈でコードを書き換えたら、プロジェクトは一瞬で崩壊する。

並列処理のパワーは、制御を失えばただの破壊兵器になる。

ここでも制約設計が火を噴く。

コーディネーターとなるメインDevinに対して、各子Devinの役割、入力スキーマ、出力フォーマットを厳密に定義する。

「このディレクトリのファイルだけを触れ」。

「出力はこのJSON形式に限定しろ」。

明確な境界条件を設定する。

そうしないと、高いAPI利用料を払って、プロジェクトを破壊するだけのゴミが出来上がる。

コードを書くのはAIだ。

僕ら開発者の仕事は、AIが迷走しないための壁を作ることだ。

ドメイン知識を探索させ、構造化された制約で縛り、並列エージェントを指揮する。

AIを野放しにせず、ガチガチのレールの上を走らせる。

これが、これからの1人SaaS開発の絶対条件だ。

開発者は「コードを書く作業者」から「アーキテクト」へ

で、僕らの日々の開発にどう落とし込むか。

エディタを開いて、いきなりAIにコードを書かせる癖を捨てる。

そのプロセス自体が、すでにレガシーだ。

まずは要件JSONを書かせる。

次にAPIスキーマを定義させる。

その次にUIのデータ構造を決めさせる。

コード生成は一番最後だ。

各ステップで、AIに「構造化成果物」を出力させる。

自然言語のやり取りは、解釈のブレを生む。

JSONやYAMLといった、機械的に検証可能なフォーマットで中間状態を固定する。

これが、AIの出力を安定させる最強のハックだ。

しんたろー：
これ見て、うちの構成だとAPIのスキーマ定義をどうAIに食わせるかが気になった。
曖昧なプロンプトは百害あって一利なし。
表形式で論理の飛躍を防ぐアプローチは即採用だ。

そして、AIを「単なるコード補完ツール」として扱うのをやめる。

AIは、論文を読み解く研究者であり、タスクを分割するテックリードであり、テストを並列実行するQAエンジニアだ。

僕らは彼らを束ねるプロダクトマネージャー兼アーキテクトとして振る舞う。

役割分担を明確にする。

人間は方針を決め、制約を設計し、最終的な判断を下す。

実装の泥臭い作業はすべてAIの並列処理に投げ込む。

専門外の機能実装を恐れる必要はない。

AIに「この分野のベストプラクティスを調べろ」と指示すればいい。

出てきた手法を比較し、制約を設計し、実装を指揮する。

1人の開発者が、巨大な開発チームと同じスピードと品質でプロダクトを作れる。

未知の領域にも、AIという優秀な探索者を送り込める。

ただし、コスト管理はシビアに設定する。

マルチエージェントを無計画に走らせれば、APIの課金は一瞬で跳ね上がる。

並列処理させるタスクは、境界が明確で、手順が確立しているものに限定する。

大規模なリファクタリングや、全画面のテストなどだ。

要件がフワッとした状態で並列エージェントを起動するのは、お金をドブに捨てるのと同じだ。

各セッションの計算リソース使用量を常にトラッキングする。

不要なセッションは即座に停止させる仕組みを作る。

AIモデルが進化し、内部構造がブラックボックス化していく。

僕らがコントロールできるのは「入力」と「出力の枠組み」だけだ。

外側から意味の通路を設計する。

モデルの機嫌を取るのではなく、システムとして逃げ道を塞ぐ。

コードを書くスピードではなく、制約を設計する精度が問われている。

AIエージェントを使いこなすためのFAQ

AIに専門外の論文や特許を調べさせて実装に落とし込む際のコツは？

いきなり「〇〇の機能を作って」と指示するのは最悪だ。

まずは「〇〇の課題に対する学術的なアプローチは？」と問い、複数の手法を比較させる。

その後、採用する手法の原理と構成を、JSONやMarkdownなどの「構造化成果物」として出力させる。

方針を人間がレビューし、ガチガチに固定してから実装フェーズに進む。

この中間ステップを挟むだけで、手戻りは80%減る。

AIの文脈喪失を防ぐ最強の防波堤になる。

マルチエージェント機能は、個人開発でもコストに見合う？

使い方次第だ。

大規模なリファクタリングや全画面のE2Eテストなど、人間がやると数時間から数日かかる単純並列作業なら、スポットでの課金は十分にペイする。

ただし、要件が曖昧な状態で走らせると、無駄なセッションが無限に立ち上がりコストが跳ね上がる。

事前にタスクの境界条件と出力フォーマットを明確に定義し、AIの暴走を防ぐ設計が必須だ。

投資対効果を見極め、明確なタスクにのみ投入する。

最近のAIモデルが「慎重になった」「言うことを聞かない」と感じる場合の対策は？

モデル内部のセーフティフィルターやルーターが干渉している可能性が高い。

プロンプトの言い回しを微調整する小手先のテクニックは通用しない。

出力形式を厳密なJSONスキーマで指定する。

中間ステップ（要件定義→API設計→コード生成）を細かく分け、各段階で出力を固定する。

外側から「意味の通路」を狭める制約設計に切り替える。

AIの自由度を奪うことが、安定した出力を生む。

構造化された制約でAIを支配しろ

AIにコードを書かせる時代から、AIの暴走を制約で縛り付ける時代へ。

曖昧なプロンプトを捨て、JSONとスキーマでAIの退路を断つ。

この設計力こそが、1人SaaS開発の勝敗を分ける。

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