資料が3件並ぶページができました。次に検索を付けたいと思ったとき、「便利にして」だけで頼むと、AIは便利の中身を推測します。ログインやデータベースまで提案されるかもしれません。
まず、今回どこまで作るかを決めます。依頼書は長い企画書ではありません。今回の作業を確かめるための、短いメモです。
今日はBRIEF.mdというファイルに依頼書を残し、計画を読みます。この回では、まだ実装しません。
6項目の依頼書
| 項目 | この実習で書くこと |
|---|---|
| 誰が使うか | 架空の小さなチームのメンバー |
| 何を助けるか | 名前をうろ覚えでも、仕事の資料を見つける |
| 入力は何か | 架空の資料6件。名前、カテゴリ、説明、タグ |
| 何を作るか | 一覧、文字検索、カテゴリ絞り込みがある1ページ |
| 制約は何か | ファイルを直接開く。サーバー、ログイン、外部通信なし |
| 何で合否を決めるか | 指定した検索とカテゴリ操作の結果を確かめる |
最後の項目が受入条件です。依頼した人が結果を受け取ってよいと判断するための、観察できる条件を指します。
「使いやすい」だけでは、どこを見れば合格かが曖昧です。「空の検索では6件が表示される」「該当しない語では0件と表示される」なら、画面で確かめられます。
BRIEF.mdに残す
knowledge-desk-practiceの会話で、次の指示を送ります。Markdownのファイルは、普通のテキストに見出しなどを付けたものです。専用のソフトがなくても読めます。
このフォルダにBRIEF.mdを作ってください。
6項目で、次の実習の依頼書を残します。
誰：架空の小さなチームのメンバー。
目的：名前をうろ覚えでも仕事の資料を探せる。
入力：学習用の架空の資料6件。id、title、category、summary、tagsを持つ。
出力：資料一覧、文字検索、カテゴリ絞り込みがある1ページのナレッジデスク。
制約：index.htmlを直接開く。HTML/CSS/JavaScriptだけを使い、サーバー、ログイン、API、外部通信、追加パッケージは使わない。
受入条件：検索が空なら6件。『議事録』なら会議の資料1件。『学び』カテゴリなら2件。該当しない語なら0件の案内。検索を消しカテゴリを『すべて』に戻すと6件。
今日はBRIEF.mdの作成だけにし、index.htmlは変更しないでください。作った依頼書を開いて読みます。この実習で使う6件の資料は、次の回で配布データから用意します。この時点で画面が3件のままでも問題ありません。
受入条件を自分で変えたい場合は、資料と一致するようにします。たとえば「学びは3件」と変えるなら、そのカテゴリの入力資料も3件必要になります。
Planモードで計画を読む
Codeタブの送信欄の近くにある権限モードの選択欄で、Planを選びます。ターミナル版のショートカットを使わず、画面の選択欄で切り替えてください。
Anthropicは、探索と計画を実装から分ける進め方を公式のBest practicesで説明しています。この実習では、受入条件に合う計画かを自分で読むために使います。
BRIEF.mdと今のindex.htmlを読んで、実装計画を提案してください。
まだアプリのファイルは変更しないでください。
資料の表示、文字検索、カテゴリ絞り込みの順に分けます。各段階で変更するファイルと、私がブラウザで確かめる操作を書いてください。
サーバーやAPI、追加パッケージが必要だと思ったら、導入せず理由を説明してください。
計画の最後に、受入条件のどれを各段階で確認するかを対応させてください。計画では、変更するファイル、増える機能、確認する操作を読みます。頼んでいない機能が増えていたら、いまは外してもらいます。
たとえばログインや外部保存は、この実習の制約に合いません。検索を付ける前に一覧が見えることを確かめる段階がなければ、計画を分け直します。
ログインと外部保存は今回の範囲から外してください。
まず資料6件を表示する段階だけに分け、その後に検索、最後にカテゴリを追加する計画に直してください。
0件になったときの案内と、6件に戻す操作も確認項目に入れてください。計画を確認したら、次の回へ進みます。実装するときはPlanからManualなどの実装を進めるモードへ戻します。モードの表示を見てから依頼してください。
この回の合格条件
BRIEF.mdに6項目があり、受入条件が画面で確認できる言葉になっている。- 計画が、表示、検索、カテゴリの順に分かれている。
- 計画に、変更するファイルと自分が確かめる操作がある。
- サーバーやログインなど、今回の範囲外の機能が入っていない。
見た目のもっともらしさだけで判断せず、計画と依頼書の条件を照合してください。
つまずいたとき
| 起きたこと | 戻すための依頼 |
|---|---|
| 計画の用語が読めない | 「各ファイルの役割を、今回の画面で何をするかに言い換えて」 |
| 機能が増え続ける | 「BRIEF.mdの出力だけに絞って。追加案は別の箇条書きにして」 |
| Planのまま作業が進まない | 計画を確認した後、送信欄のモードをManualに切り替える |
| 何を見れば合格か分からない | 「私が入力する値と、表示されるべき件数を対にして」 |
曖昧な受入条件は、実装の前に直せます。ここで決めた条件は、後のテストにも使います。
今日のまとめ
- 誰の何を助けるかを、6項目の依頼書に残しました。
- Planモードで、ファイルを変える前の計画を読みました。
- 計画を受入条件と照らし合わせ、作る範囲を絞りました。
次は資料と約束事を、置き場所で分ける回です。依頼書を毎回貼り直さずに済むようにします。
セルフチェック
1. 画面で確かめられる受入条件はどれですか。
2. Planが今回不要なログイン機能を提案したとき、適切な対応はどれですか。
参考・出典
- Anthropic: Codeタブの権限モード。デスクトップのモード選択欄とPlanを確認。
- Anthropic: Best practices。探索、計画、実装、検証を分ける説明を参照。
操作説明の確認日: 2026年10月10日。6項目の依頼書と受入条件は、この実習のための教材です。