プロダクトの体験・目的と、技術の意図を一つのツリーに

多くのチームが抱える分断

• デザイナー文書 / Figma コメント / PRD (プロダクト体験・目的の側)
• ADR / RFC / runbook (バックエンド側)
• なぜ乖離するか: 読者が違い、レビュー頻度が違い、ツールが違います。

Intent は「動作だけを指定するプログラミング」ではない

意図で駆動する開発は、外から見ると、vibe coding のようにコードをまったく見ず、動作だけを指定するものに見えるかもしれません。技術的な判断を持たない人が、技術的な指示を何もせずに進めれば、実際にそのような形になります。けれど、ここで言っているモデルはそれだけではありません。

開発企業である私たちが実践するとき、Intent にはより高いレベルの技術判断も含めます。どの技術を採用してほしいのか、部品の間にどのようなインターフェースを形成してほしいのか、そのインターフェースを自然に実践できる構造にしてほしいのか、どの方針で問題を解いてほしいのか。クラスやコード行を細かく管理する必要はありませんが、実装を制約すべき技術的な方向性は記録できます。

設計ループが「意図」と「実際に作られたもの」の差を埋める

Intent-System は、ひと回しで完成品を作るわけではありません。出てくるのは、継続的にマージされる差分の流れです。設計ループは、その差分が正しい方向に向き続けるための仕組みです ── 設計スレッドは次の判断をコードを読んで下すのではなく、「実装が実際に何を作ったか」を画面で見て、それが狙い通りかを判断します。

設計スレッドは、結果を確かめるために自分で動作中のアプリを操作します。ネイティブ画面なら Computer Use、Web 画面なら設計スレッドの中から呼び出す Playwright CLI を使います。packet を書いたのと同じスレッドが、稼働中のアプリを開き、出力を packet・intent スライス・ツリー全体と突き合わせ、自分で一次判断を出す ── 意図を書いた者が、意図が守られたかを確認します。

結果がズレている場合 ── 微妙な UX のミス、Intent に書いた意味とは違う解釈で作られた画面、隣接フローのリグレッション、動かしてみないと出ないインテグレーションの不具合 ── 設計スレッドはチャットを投げて待つのではなく、その場で新しい packet を出します。調整 packet、あるいはバグ修正 packet を、画面レベルの観察を添えて発行します。次の /loop tick で実装スレッドが拾うので、「なんか違う」が誰かの手で起票されるのを待たずに前に進みます。

このチェックから出てくるのは 2 つのケースで、保存された意図があるおかげで両者は見分けやすくなります。実装が明らかに意図に反していれば、それはバグ修正 packet で、実装スレッドが直します。一方、意図がはっきり述べていなかったことを実装が妥当に推測していた場合は、それはバグではなく「意図をより詳細に述べるべき」というサインで、調整 packet が同時にツリーを鋭くします。そして、このチェックを行うのは設計スレッドだけではありません ── 人間も定期的にプロダクトを実際に動かし、気づいたことを同じ経路で戻します。どのプロダクトも、ひと回しで完成する前提は置かず、定期的に動かしてフィードバックすることが意図されています。

これがあるからシステムは「操縦可能」であり続けます。統合された Intent ツリーは静的な構造、設計ループ ── 見る・判断する・フィードバック packet を出す ── は、その構造が育っていくプロダクトの現実に追随し続けるための仕組みです。「もっとこうしてほしい」はツリーに残り、誰かの記憶の中で消えていくことはありません。

Intent Storming ── 統合ツリーの種まき

統合された Intent ツリーは、ある日突然できあがるものではありません。種まきとして私たちが使っているのが Intent Storming と呼ぶプロセスです ── プロダクトオーナーとして技術と意図をまとめていく作業です。ブレインストーミングや Event Storming と同じ姿勢で行いますが、終わったときに手元に残るのは Intent ツリーです。

進め方は二通りあります。ワークショップとして行う場合は、プロダクトオーナーとエンジニア（UI が論点ならデザイナーも）が同じ場に集まり、ツリーが要求する問いに順番に答えていきます ── なぜこれをやるのか、誰のためか、MVP は何ができれば良いのか、どのトレードオフはすでに受け入れているか。あるいは一人でも行えます ── 一人がプロダクトオーナーを務め、intent-cli に導かれた AI が、未決定の論点ごとに背景・選択肢・利点と欠点・推奨を提示しながらヒアリングします。どちらの場合も、出てきた答えは議事録ではなく、Purpose / User Context / Means の各ノードとしてその場で Intent ツリーに書き込まれます。あとで誰かが「議事録から intent に翻訳する」工程は要りません。

もっとも効くのは、ミッション・ビジョン・MVP の形がまだ動いているプロダクトの最初期です。この段階で canonical な意図として書き留めておけば、以後の実装スライスは自動的にそれを受け継ぎます。「言っていたこと」と「実際に作ったもの」の間に drift を持ち込むのが、ずっと難しくなります。

セッションの最中・直後には、LLM が intent レビューを走らせ、クラリフィケーション（明確化のための問い）をチームに返します ── 「空状態はどう振る舞うべき？」「最も大事な成功指標はどれ？」「日本市場と海外市場は同じ扱い？」といった具合です。チームはこだわりがある問いだけ自分で答え、それ以外は推奨案を採用する。これによって、画面の一要素からプロダクト全体のコンセプトまで、必要な粒度のものだけを「固定」できます。最初は少数のポイントだけを伝えて開発を始め、どうしても守ってほしい詳細は、その都度 intent として足していけばよい ── そのバランスを成り立たせるのが Intent Storming + クラリフィケーションのループです。