INTENT.md とは何か — AI ネイティブ SDLC の最初のファイル

INTENT.md に何を書くのか

INTENT.md は、作りたいものをアイデアを出した本人の言葉で記録する Markdown ファイルである。Markdown は見出しと箇条書き程度の軽い書式しか持たないテキストで、拡張子は .md だ。ワープロ文書や社内 wiki ではなく、コードと同じリポジトリに入ることが要点である。

Anthropic は 2026 年 8 月 21 日に公開した AI ネイティブ SDLC プレイブックで、このファイルに六つが入ると記した。何が問題なのか、解決すればどんな状態になるのか、どのユーザーとどのシステムが影響を受けるのか、どんな制約があるのか、まだ解けていない問いは何か、そして作成者と現在の状態である。

六項目はテンプレートを埋めるためにあるのではない。次の段階で設計文書を作るときに必要な材料が、ちょうどこれらなのだ。制約が抜ければ実行できない設計が出てくるし、未解決の問いが抜ければ推測を確定事項として書いた設計が出てくる。

なぜコードより先に意図を書くのか

SDLC はソフトウェア開発ライフサイクルを指す。計画し、設計し、作り、テストし、デプロイし、保守するという一周のことだ。機能をひとつ出すたびにチームが回るこの循環が SDLC である。

この六区間のうち、長らく時間と費用がかかっていたのは作る区間だった。だから開発ツールも採用もそこに集中した。コーディングエージェントが実務に入って変わったのがこの点である。作る時間が縮んだことで、残る五区間が日程のなかで相対的に大きく見えるようになった。

要件を集める会議、文書担当を待つ時間、テスターの順番を待つ数日、レビュー待ちで滞留する PR は、そのままだ。コードが速くなっても、機能ひとつが利用者に届くまでの時間は同じだけ縮まない。ボトルネックがコードからプロセスへ移ったのである。

プレイブックの問題意識はここにある。エージェントを作る区間だけで使わず前後の区間にも入れよう、そのためには各区間が次の区間へ渡すものが会話ではなくファイルでなければならない、ということだ。INTENT.md がその最初のファイルである。

いますぐ書いてみる手順

必要なのはフォルダひとつだ。リポジトリの最上位に intent という名のフォルダを作る。プレイブックは、製品がひとつのチームならその製品リポジトリ内の intent フォルダが最も単純な置き場だと記している。

次にエージェントに自分をインタビューさせる。ここでは順序が重要だ。こちらが要件を整理して渡すのではなく、エージェントが問い続けて頭のなかにあるものを引き出す側である。整理して渡すと、整理の途中で落としたものは二度と出てこない。

ダークモードを入れたいとしよう。なぜ必要か、どの画面が関わるか、利用者の設定をどこに保存するか、画像やロゴをどうするか、いつまでに必要か、何を諦められるかを問い続けさせる。答えることがなくなるまで進んでから、ファイルとして保存させる。

Claude Code や Cursor のようにファイルを直接作れるツールを使っているなら、対話の最後に保存まで任せればよい。ウェブのチャットなら結果をコピーしてファイルに貼り付ける。ファイル名は機能が分かるように付ける。intent/dark-mode.md のようにするか、日付を先頭に付けて並ぶようにしてもよい。

これから私が作ろうとしている機能について質問してください。
一度にひとつずつ、私がもう答えることがないと言うまで聞いてください。

聞くこと: この機能が必要な理由、いま何が不便か、
影響を受ける利用者と画面、つながっている他のシステム、予算・期限・技術上の制約、
まだ決めていないこと。

私が「もういい」と言ったら、対話をまとめて intent/<機能名>.md として保存してください。
形式: 問題 / 目標の状態 / 影響範囲 / 制約 / 未解決の問い / 作成者と状態

# ダークモード

## 問題
夜間にアプリを使う利用者から、画面が明るくて眩しいという問い合わせがこの三か月で繰り返し届いている。

## 目標の状態
利用者が設定で明るい画面と暗い画面を選べ、端末のシステム設定に従う選択肢もある。

## 影響範囲
アプリの全画面。設定画面に項目をひとつ追加。ロゴとイラストは明るい背景を前提に作られているため見直しが要る。

## 制約
次の四半期の定期リリースに入れる必要がある。デザインシステムの色トークンを新設する余力はなく、既存トークンの再利用の範囲で解決する。

## 未解決の問い
利用者の選択を端末だけに保存するか、アカウントに保存して端末間で同期するかを決めていない。
メールのテンプレートまで対応するか、範囲から外すかを決めていない。

## 作成者と状態
作成 申丞浩 · 2026-09-05 · レビュー待ち

本人が読み返す段階を飛ばさない

エージェントがファイルを作った時点が終わりではない。プレイブックは、アイデアを出した本人がその結果を読み返して直してからコミットせよと記している。この段階はこのやり方のなかで最も飛ばされやすく、飛ばしたときの損が最も大きい。

理由は後ろの構造にある。このファイルは次の段階で設計文書になり、設計文書はその次に作業計画になり、計画はコードになる。各段階は前段階のファイルだけを読む。だから最初のファイルに誤って書かれた一文は、静かに三段階を通ってコードまで届く。

実際にずれやすい箇所は決まっている。エージェントは対話のなかで通りすがりに言ったことを確定した要件として書き留める傾向があり、逆にこちらが当然と思って言わなかった制約は無いものとして書く。読むときはこの二つをまず見る。

直すときは文を整えるより事実関係を見る。決めていないことが決まったように書かれていれば未解決の問いに下げ、範囲外と考えていたものが影響範囲に入っていれば外す。レビューが終わればコミットし、プレイブックはその承認自体を文書のマージ、あるいは閉じられたレビューとして記録せよと記している。

作成者は開発者でなくてよい

プレイブックはこのファイルを書く人を発案者と呼ぶ。組織のなかでアイデアを持つ人なら誰でも発案者になれる、というのがこの語の要点だ。

不具合に遭った顧客が発案者でありうる。機能のアイデアを持つ企画担当も、繰り返しの手作業をなくしたい運用担当も発案者だ。これまでこうした依頼は一行のチケットとして受け付けられ、誰かが聞き直して整理する必要があった。その整理をエージェントが代わりに行うので、経験した本人が経験した言葉のまま残せる。

とはいえ全部がそのまま開発に進むわけではない。集まったファイルはプロダクトの責任者が目を通し、優先順位を決める。フォルダに溜まった Markdown ファイルの一覧そのものがバックログになり、チームによってはこの一覧を Notion や Linear のような道具に移して管理する。分類と優先度の草案をエージェントに先に作らせ、人が確定する方式も使える。

INTENT.md の次に来るもの — 成果物の連なり

このファイルは単独では存在しない。プレイブックは段階ごとに残る成果物をつないだ鎖を示しており、INTENT.md はその最初の輪である。

意図がコミットされると、それを材料に要件と設計を収めた spec.md を作る。プレイブックはこの段階で使う指示の例も示している。添付した intent.md を読んで要件と設計の文書を作り、使えるスキルを適用してブランドガイドライン・セキュリティ方針・UX 基準に合わせよ、という内容だ。

設計が決まると、エンジニアが意図と設計を合わせて入力し、作業計画である plan.md を作る。どのファイルを直すか、どの順で行うか、何が危険か、完了を何で確かめるかがここに入る。計画の良し悪しを判断する基準のひとつは、この文書だけを受け取った人が前の二つを見ずに作業できるかどうかである。

この基準は厳しく見えるが理由がある。六区間をひとつのエージェントが最初から最後まで担当しないからだ。段階ごとに別の対話、別のエージェント、別のサブエージェントが付き、彼らは先の対話を知らない。渡すものが会話ではなくファイルでなければならないという言葉が、ここで好みではなく実務上の要求になる。

チームに入れる前に決めておくこと

フォルダひとつで始められるが、チームに定着させるにはいくつか先に決めておくほうがよい。ファイルをどこに置くか、名前をどう付けるか、誰がレビューして何で承認を示すかだ。頻繁に変えると人もエージェントも毎回違う規則に出会い、利点が消える。

規則を文書に留めず、実行されるようにもできる。意図がマージされたら設計文書の生成を走らせるフックを置いたり、チームで使う文書の形式をスキルにしておけば、毎回指示を書き直さずに済む。プレイブックがガバナンスをコードとして置けと言うのはこの部分である。

すでに回っているやり方があるなら、まるごと入れ替える理由はない。各チームはすでに自分たちの計画文書とレビュー手順を持っており、このプレイブックもひとつのやり方にすぎない。重なる部分は名前を合わせ、いま空いている一枠から埋めるほうが定着しやすい。

最も小さく始める方法は、今週出す機能をひとつ選び、intent フォルダにファイルをひとつ作ってみることだ。そのファイルだけで次の人が設計を始められるかを見れば、このやり方が自分のチームに要るかどうかが一度で分かる。