【非エンジニア編第14回】議事録・要件をClaude Codeで技術的な言葉に変換する

※Claude Codeを使用して記事を作成しています。

前回の記事では、バグ報告をClaude Codeで整理してからエンジニアに渡す方法を紹介しました。

第4部「実務シーン編」の2回目は、

議事録・要件の変換

です。

打ち合わせで決まったことを、エンジニアにうまく伝えられない
議事録を渡したのに、「結局、何を作ればいいのですか?」と聞かれた
「いい感じに」「なるべく早く」といった曖昧な表現が、そのまま残ってしまう

ビジネス側の言葉で交わされた会話は、そのままではエンジニアが実装に使えないことがあります。

Claude Codeを使って、議事録や要件を、エンジニアが扱いやすい形に変換する方法を紹介します。

なぜ議事録がそのままでは伝わらないのか

議事録がエンジニアに伝わりにくい理由は、主に以下の4つです。

決定事項と議論の経過が混ざっている
何が決まったのかが、文章の中に埋もれている
曖昧な表現が残っている
「使いやすく」「早めに」など、基準が書かれていない
前提が省略されている
参加者にとっては当たり前の背景が、書かれていない
未決事項が見えない
「後で決める」と言った内容が、記録に残っていない

これらは、議事録の書き方が悪いというより、

参加者同士が共有している前提を、
そのまま書いてしまう

ことから起きます。

Claude Codeは、この前提の抜けを見つけて、整理し直す役割を果たせます。

Claude Codeにできることと、できないこと

最初に、役割を整理しておきます。

Claude Codeにできるのは、

議事録から、決定事項・ToDo・未決事項を分けて整理する
曖昧な表現を見つけて、確認事項として切り出す
ビジネスの言葉を、要件に近い書き方に言い換える

ことです。

一方で、できないのは、

会議で実際に何が合意されたかを判断すること
書かれていない内容を、正しく補うこと

です。

議事録に書かれていないことは、Claude Codeにもわからない

という前提を持っておくことが重要です。

実例:打ち合わせの議事録を整理する

ここでは、「会員向けのポイント機能」について話し合った打ち合わせの議事録を例にします。
内容は説明のための仮の例です。

【議事録(元の文章)】

・会員が買い物をしたらポイントが貯まるようにしたい
・ポイントはできるだけ早くお客様に付与したい
・有効期限は一年くらいで考えている
・貯まったポイントは次回の買い物で使えるようにしたい
・使いやすい画面にしてほしい
・退会したときのポイントの扱いは、また相談する
・来月の営業会議までに、方向性を固めたい

このままエンジニアに渡すと、確認の質問が何往復も発生しそうです。

ステップ1:決定事項・ToDo・未決事項に分ける

まず、議事録の内容を種類ごとに分類してもらいます。

【質問例】
以下の議事録を、
「決定事項」「ToDo」「未決事項」「曖昧な表現」に分類してください。
議事録に書かれていないことは、補わないでください。

(議事録を貼り付ける)

「補わないでください」と伝えることがポイントです。
指定しないと、一般的な内容で勝手に補完されてしまうことがあります。

Claude Codeが、以下のように分類してくれます。

【分類例】

■ 決定事項（と読み取れるもの）
- 会員が買い物をするとポイントが貯まる
- 貯まったポイントは次回の買い物で使える

■ ToDo
- 来月の営業会議までに、方向性を固める

■ 未決事項
- 退会時のポイントの扱い

■ 曖昧な表現
- 「できるだけ早く」付与したい（いつ付与するのか不明）
- 有効期限は「一年くらい」（正確な期間が不明）
- 「使いやすい画面」（基準が不明）

会話の中に埋もれていた論点が、一覧として見えるようになります。

ステップ2:曖昧な表現を確認事項に変える

分類の中で見つかった曖昧な表現は、そのままでは実装に使えません。

確認すべき質問に変換してもらいます。

【質問例】
「曖昧な表現」として挙がった項目について、
エンジニアが実装するために確認が必要な質問を作成してください。

Claude Codeが、以下のように変換してくれます。

【確認事項の例】

■ ポイントの付与タイミング
- 購入の確定直後に付与するのか、発送完了後に付与するのか
- 返品やキャンセルがあった場合、付与済みのポイントはどうするのか

■ 有効期限
- 「一年」は、付与日から365日なのか、付与した年の年末までなのか
- 期限切れの前に、ユーザーへ通知するのか

■ 画面
- 「使いやすい」とは、具体的にどのような状態か
  （例:ポイント残高が一目でわかる、など）
- 既存のデザインに合わせるのか、新しく設計するのか

「できるだけ早く」という一言から、実装に必要な論点が複数出てきました。

これらを打ち合わせの関係者に確認することで、エンジニアの手戻りを防げます。

ステップ3:要件に近い書き方に言い換える

確認が取れた内容をもとに、要件の書き方に整えてもらいます。

【質問例】
以下の確認結果をもとに、エンジニアが読んで実装の判断ができる形の要件として
整理してください。
確認が取れていない項目は、「未確定」と明記してください。

【確認結果】
- ポイントは、発送完了時に付与する
- 付与の割合は、購入金額の1%
- 有効期限は、付与日から1年間
- 期限切れの通知は未定
- 退会時の扱いは未定

Claude Codeが、以下のように整理してくれます。

【要件の整理例】

■ ポイントの付与
- 付与のタイミング:発送完了時
- 付与の割合:購入金額の1%
- 付与の対象:会員のみ

■ ポイントの有効期限
- 付与日から1年間
- 期限を過ぎたポイントは失効する

■ ポイントの利用
- 貯まったポイントは、次回以降の買い物で利用できる

■ 未確定事項
- 期限切れ前の通知の有無
- 退会時のポイントの扱い
- 返品・キャンセル時の付与済みポイントの扱い
- 端数が出た場合の処理（切り捨て・切り上げなど）

ビジネス側の言葉が、「いつ」「何に」「どうなる」という形に変換されました。

ここでも、

確認が取れていないことは「未確定」と書く

ことを徹底します。

ステップ4:エンジニア目線で抜けがないか確認する

整理した要件を、エンジニアの立場で読み直してもらいます。

【質問例】
以下の要件を、実装を担当するエンジニアの立場で読んでください。
実装前に確認したくなる点や、要件として抜けていそうな観点があれば
指摘してください。

(整理した要件を貼り付ける)

Claude Codeが、以下のような指摘を返してくれます。

【指摘例】

- ポイントを使う際に、一部だけ使うことはできるのか
  （例:残高500ポイントのうち200ポイントだけ使う）
- 複数のポイントで有効期限が異なる場合、どの順番で消費するのか
- ポイントの付与・利用の履歴を、ユーザーが確認できる必要があるか
- すでに登録済みの会員に対して、過去の購入分のポイントを付与するのか

こうした指摘は、打ち合わせの場では出てこなかった論点です。

議事録の段階で気づければ、開発が始まってからの手戻りを減らせます。

議事録の変換でやってはいけないこと

AIが補った内容を、決定事項として扱う

Claude Codeが整理する際に、一般的な内容で補ってしまうことがあります。

例えば「付与の割合は1%」のような数字を、議事録に書かれていないのに出力してしまう場合があります。

整理された内容は必ず元の議事録と照らし合わせて、

これは議事録に書かれていたことか、
AIが補ったことか

を確認してください。

そのために、最初の依頼で「補わないでください」と伝えておくことが有効です。

参加者への確認を省略する

整理した内容は、あくまで「議事録から読み取れる範囲」の整理です。

実際の打ち合わせで何が合意されていたかは、参加者にしかわかりません。

エンジニアに渡す前に、参加者に内容を確認してもらってください。

【質問例】
整理した内容を、打ち合わせの参加者に確認してもらうための連絡文を作成してください。
「この理解で合っているか」を確認する形にしてください。

機密情報をそのまま入力する

議事録には、取引先名や未公開の施策など、社外に出せない情報が含まれることがあります。

入力する前に、

固有名詞は「A社」「新サービス」のように置き換える
社内のAI利用ルールに従う

ことを確認してください。

議事録変換のテンプレート

【議事録変換テンプレート】

1. 以下の議事録を、
   「決定事項」「ToDo」「未決事項」「曖昧な表現」に分類してください。
   議事録に書かれていないことは、補わないでください。
   （議事録を貼り付ける）

2. 「曖昧な表現」として挙がった項目について、
   エンジニアが実装するために確認が必要な質問を作成してください。

3. 以下の確認結果をもとに、
   エンジニアが読んで判断できる形の要件として整理してください。
   確認が取れていない項目は「未確定」と明記してください。
   （確認結果を書く）

4. この要件を実装担当のエンジニアの立場で読んで、
   確認したくなる点や抜けていそうな観点を指摘してください。

5. 整理した内容を、打ち合わせの参加者に確認してもらうための
   連絡文を作成してください。