数十人月の開発を1週間で完了。Claude Codeによる一人SaaS開発で必須となる文脈共有の仕組み

出た。数十人月規模の開発をたった1週間で終わらせた事例。

ロケーション51箇所。背景画像129枚。会話エンジンの新規設計。

これをPdM1人とAIだけで作り切ったという事実。

一方で、非エンジニア向けのエージェント構築ツールが5000万ドル（約75億円）を調達した。

コードを書くコストは、完全にゼロに近づいている。

じゃあ開発は楽になったのか。全く逆だ。

「AIに文脈を理解させる」「AIの出力を人間が理解する」。

この新しい地獄が始まっている。

開発のボトルネックが「実装」から「文脈」へ

最近のAI開発の現場で起きている地殻変動。

複数の事例や調達ニュースを繋ぎ合わせると、明確なトレンドが見える。

まず、圧倒的な開発スピードの事例だ。

あるtoCエンタメアプリの開発。

ゲーム的なUIとチャットAIを融合させた、ノベルゲームに近い体験。

普通に作れば体験設計から実装まで数十人月かかる規模だ。

これを、PdM1人とAIだけで約1週間で「これで行ける」という状態まで作り上げた。

AIを単なる「コード生成機」として使わなかった点が核心だ。

モック、仕様書、マスター設計、素材生成ツール、変更履歴。

これらを全て1つのポータルにまとめ、AIをそこに住まわせた。

AIは「文脈を共有した作業者」になった。

次に、エージェント構築プラットフォームの大型調達。

設立わずか8ヶ月のスタートアップが、5000万ドルという巨額の資金を集めた。

非エンジニアの社員が、自分で自律型AIエージェントを作れるツールだ。

Shopifyなどの大企業で、社員が勝手に業務自動化エージェントを量産している。

エンジニアは一切関与していない。

社員が自分でエージェントを作り、同僚にシェアし、会社全体がAIネイティブになっていく。

そして、現場のエンジニアからの悲鳴。

「コードを書くコストはゼロになったが、コードを理解するコストが爆増している」

AIは数百行のコードを一瞬で吐き出す。

しかし、人間がそれを理解する速度は変わらない。

抽象的だった実装方針が、一瞬で大量のコードとして具体化される。

さらに、AIエージェントに自律的に動いてもらうためのツール開発の現場。

「AIはマニュアルを読まない」という壁にぶち当たっている。

READMEもヘルプも読まず、いきなりコマンドを叩く。

そしてエラーを出して止まる。

これらが示しているのは、開発のボトルネックが完全に移行したということだ。

「どう実装するか」ではない。

「どうやってAIと文脈を共有するか」だ。

AIは一瞬でコードを書く。しかし、プロジェクトの背景を知らない。

人間はAIのコードを一瞬で手に入れる。しかし、その意図を理解できない。

この「文脈の断絶」をどう繋ぐかが、今の開発の最前線になっている。

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

プロンプトではなく環境を作る

ここからは僕の視点。

Claude Codeで毎日コードを書いていると、この「文脈の共有」という壁に何度もぶち当たる。

AIは一瞬でコードを書く。

でも、セッションが切れると全てを忘れる。

「なぜこの実装にしたのか」「過去に何を試して失敗したのか」。

これが抜け落ちる。

数十人月を1週間で終わらせた事例の勝因は、プロンプトの工夫ではない。

「環境」を作ったことだ。

モックと仕様とマスターデータが連動するポータル。

何かを変更する時、見た目、意図、仕様、運用が切り離されていない。

だからAIは文脈を見失わずに動ける。

「なぜこうなっているか」を毎回説明する必要がない。

AIに全部任せると出力が不安定になる。

だから、ロジックで持つべき部分とLLMに委ねる部分の境界線を引く必要がある。

仕様書の上で決めるのは不可能だ。

動かして確かめて、また動かす。

そのために、モックと設定パネルが一体化した環境が必要になる。

担当範囲が明確になれば、AIはその中で最大限の品質を出せる。

しんたろー：
Claude Code使ってて一番キツいのが、セッション再開時の「お前誰だっけ」状態。
毎回プロジェクトの背景を説明し直すのは本当に骨が折れる。
環境ごと渡して「ここ見て動け」ができるなら、うちの開発フローも根本から変えられそうだと思った。

さらに気になるのが、AI向けのUX設計だ。

ある文献検索CLIツールの開発事例がある。

AIエージェントに複数のデータベースを横断検索させる。

単発のコマンドではなく、多段階の自律的な判断が必要なタスクだ。

ここで開発者は気づいた。

「AIはマニュアルを読まない」。

人間と同じだ。とりあえず触って、結果を見て覚える。

しかし、人間とAIには決定的な違いがある。

人間はUIの視覚的手がかりから次を推測できる。

ボタンの配置やグレーアウトされた項目が「次に何ができるか」を暗黙に伝える。

AIにはそれがない。

テキスト出力が全てだ。

だから、CLIの全ての出力に「次に何をすべきか」を含める必要がある。

検索が成功したら、単にヒット数を返すだけではダメだ。

「次はプレビューを確認しますか？ それとも本実行しますか？」

具体的なコマンド例と一緒に、次のステップを提案する。

人間なら「初回だけ表示するチュートリアル」で済む。

一度覚えれば、次からは案内なしで使える。

でもAIはセッションごとに記憶が飛ぶ。

だから「毎回表示するナビゲーション」として設計する。

これがAI向けのUXだ。

非エンジニアがエージェントを自作する時代。

エンジニアの仕事は、コードを書くことから「AIが迷わず動ける土台作り」にシフトしている。

コンテキストの番人になる

で、僕らの日々の開発はどう変わるのか。

AIのスピードに人間が潰される前に、開発スタイルを変える。

具体的な変化は3つだ。

1. 変更理由のドキュメント化

仕様書だけではAIは動けない。

「なぜその仕様になったのか」「何を試してダメだったのか」。

この「文脈」を残す仕組みが必須になる。

変更履歴ファイルを作る。

そこに背景と意図を蓄積し、AIの作業環境に組み込む。

セッションが切れても、AIがそこを読めば文脈を復元できるようにする。

単なるコードの履歴ではない。

思考の履歴を残す。

これがAIへの最高のインプットになる。

2. PRレビューにおける説明責任

AIが書いた大量のコード。

そのままPRを出したら、レビュワーは背景を推測しながら読解する羽目になる。

レビューコストが爆発する。

従来は「実装方針を考える」→「コードを書く」→「コードを理解する」という流れだった。

AIを使うと「AIがコードを生成する」→「抽象的だった方針が一瞬で具体化される」→「後から理解コストが発生する」。

コードは存在するが、理解のプロセスを通っていない。

これがレビューを地獄にする原因だ。

AIを使って実装したエンジニアは、「コンテキストの番人」になる。

AIが出力したコードを、プロジェクト固有の文脈に照らし合わせる。

「なぜこの実装方針を選んだのか」。

これをPRのディスクリプションで明示的に説明する。

コードを書くコストが下がった分、説明責任のハードルは上がっている。

しんたろー：
AIが吐き出した謎の最適化コード、ぱっと見は綺麗なんだけどプロジェクトの規約ガン無視とかよくある。
これをそのままPRに投げられたら、レビュワーとしては殺意が湧くレベル。
自分が書いたコードとして翻訳して説明できないなら、AI使う資格ないかも。

3. AI向けCLI・APIの設計

社内ツールやスクリプトを作る時の基準が変わる。

「AIが迷わず使えるか」が新しい設計基準だ。

エラーメッセージには必ず解決策と次のコマンドを含める。

成功時の出力にも、次に実行可能なステップを明示する。

AIはテキスト出力しか見えない。

出力結果そのものが、AIにとってのUIになる。

ここをサボると、AIエージェントは無限ループに陥るか、勝手に処理を終了する。

AIが次に打つべき手を、システム側から常に提案し続ける。

これが自律型エージェントを安定稼働させる唯一の道だ。

しんたろー：
非エンジニアがノーコードでエージェント量産する未来、すぐそこまで来てる。
エンジニアの価値って「いかにAIが使いやすいAPIを用意してあげるか」になりそうだと思った。
人間向けからAI向けへ、設計の軸足が完全に動いてる。

FAQ

Q1: AIエージェントにタスクを任せる際、コンテキスト切れをどう防げばよいですか？

単なる仕様書だけでなく、「なぜその仕様になったのか」「何を試してダメだったのか」という変更理由をマークダウン形式で蓄積するのが有効だ。AIはセッションごとに記憶を失うため、思考のプロセス自体をファイルとして保存し、毎回読み込ませる。自作のCLIツールなどをAIに使わせる場合は、ツールの出力結果に常に「次に実行可能なコマンド」を含める。これでAIが迷子になるのを防げる。

Q2: 生成AIを使った開発で、コードレビューの負担を減らすにはどうすればよいですか？

生成AIは大量のコードを一瞬で出力するため、レビュワーの理解コストが跳ね上がる。PR作成者（AIを使って実装したエンジニア）が、AIの出力結果をプロジェクト固有の文脈に翻訳する。「なぜこの実装方針を選んだのか」という背景と意図をPRのディスクリプションで明示的に説明する。AIが書いたコードであっても、最終的な文脈の担保と説明責任は人間が負わなければレビューは崩壊する。

Q3: 非エンジニア向けのAIエージェント構築ツールが普及すると、エンジニアの仕事はどう変わりますか？

単純な自動化やワークフロー構築は、ドメイン知識を持つ非エンジニア自身が行うようになる。エンジニアの役割は、それらのエージェントが安全かつ効率的に動くための基盤作りにシフトする。AIが理解しやすい社内APIやCLIの設計（AI向けUX設計）と、複雑なシステム間連携におけるコンテキストの担保。コードをゼロから書くことよりも、AIが迷わず正しく機能する土台を作ることがエンジニアの新しい主戦場だ。

まとめ

コードを書く時代から、AIに文脈を渡す時代へ。

AIエージェントが自律的に動く時代の「コンテキスト設計」や「AI向けUX」について、ThreadPostで議論しませんか？

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