ChatGPTでヒアリングをHLD初稿とBOMに

要点：ChatGPT は、とりとめのない要件ヒアリングの文字起こしを、構造化された HLD（High Level Design）初稿と初期の BOM（部品表）に、1 週間ではなく半日で変えられます。出てくるのは、認定アーキテクトが直して責任を持つための作業用ドラフトであり、設計でも見積でもありません。リスクは文章が下手なことではなく、誰も言っていないことを自信たっぷりに書くことです。

ヒアリングは順調でした。顧客の運用責任者と 90 分、最後の 20 分は財務責任者も参加し、おおむね明確な像が見えてきます。新オフィス 3 フロア、社員およそ 180 名、既存のネットワーク機器はサポート切れ、マイクロソフト継続志向、そして 11 月という動かせない期日——賃貸借がそこから始まるからです。

そして文字起こしは、フォルダの中で 11 日間眠ります。

誰かが怠けているからではありません。この打ち合わせを回した提案エンジニアは他に 2 件の案件を抱えており、90 分の入り組んだ会話を「顧客が他社の資料と比較できる文書」に変えるのは、実際に丸一日の仕事です。だから待たされます。その間に、比較検討中の顧客は他社の文書を先に受け取ります。

この 11 日の空白こそ解くに値する問題であり、しかもそれはエンジニアリングの問題ではなく文書作成の問題です。

「話しました」と「書いてあります」の差が、なぜ案件で数週間を失わせるのか

ヒアリングが生むのは共通理解ですが、それは出席者の頭の中にしか存在しません。その先のすべて——機器リスト、価格、スケジュール、社内承認、競合との比較——は、その理解が文書になることに依存しています。

文書化が遅いのは、技術的な難しさとは無関係の理由からです。会話は無秩序で、4 分目に出た要件が 61 分目に覆されます。内容の半分はそもそも要件ではありません。そして決定的なのは、抜けは書き出そうとして初めて見えるという点です。ある節に数字を入れる必要が生じるまで、無線アクセスポイントの台数が実は一度も話されていないことに誰も気づきません。

遅延のコストは具体的です。顧客のヒアリングの記憶は薄れ、それとともに「理解してもらえた」という感触も薄れます。競合状況では、最初の説得力ある文書が比較の枠組みを決め、以降は全員がその枠で評価されます。社内でも、範囲が書かれるまで見積もスケジュールも組めません。

必要なのは、より優れたアーキテクトではありません。会話からレビュー可能な初稿までの、より速い経路です。

ChatGPT が文字起こしから実際に起草できるもの

最近の ChatGPT は長い文書をよく扱え、文字起こしファイルから直接作業できます。ここで効くのは地味な能力です。構造の無いテキストを、決められた形へ忠実に組み直し、14 ページ目で飽きないこと。

本当に有用な出力は 2 つです。

HLD（高位設計）初稿のアウトライン

文字起こしと指定した文書構造を与えると、中身の入った骨格を返します。事業背景と推進要因、語られた現状、領域ごとに整理された要件、明示された制約、前提、そして最も価値があるのが、明確にスコープ外とされた項目です。

スコープ外と前提の節こそ、この手法が元を取るところです。人が書く初稿はこの 2 つを慢性的に記録し損ねます。その時点では全員が合意内容を覚えているからです。6 週間後の変更依頼の会話で「防犯カメラをやるとは一度も言っていない」が書面にあることには価値があります。

「打ち合わせで述べられたこと」と「推測したこと」を明確に区別するよう指示してください。指示のよいドラフトは推測に印を付けます。指示の無いドラフトは両者を自信ある文章に溶かし込みます——これがこの出力の最も危険な性質です。

初期の機器・ソフトウェア BOM

同じ文字起こしから、購入を示唆するものをすべて——スイッチ、アクセスポイント、ファイアウォール、ライセンス、配線、誰かが一度触れた UPS——構造化リストに抽出できます。数量が述べられていればその数量を、述べられていなければ明示的に「未指定」を入れて。

これはチェックリストであって BOM ではありません。発注できる型番も、互換性の検証も、価格もなく、実際の設計に必要でも誰も口にしなかったものは分かりません。価値は、半日ではなく 20 分で済むこと、そして抜けを早期に可視化することです。「未指定」が 11 か所並ぶリストは、次回打ち合わせの正確な議題そのものです。

これを見積として顧客に送っては絶対にいけません。価格は数量契約、地域ごとの供給状況、リードタイムに左右され、それらは文字起こしではなくサプライチェーンのチームの側にあります。

実践的な進め方——生の文字起こしからアーキテクトがレビューできる文書まで

1. どこへ出す前にも、まず文字起こしを洗う。顧客名、社名、拠点住所、話に出た金額をすべて除去します。大半は「顧客 A」「拠点 1」への置換で済みます。汎用の AI ツールにファイルを近づける前に、毎回これを最初にやります。

2. 汎用の依頼ではなく、自社のテンプレートを渡す。自社の HLD が実際に使っている節見出しを貼り付けます。「HLD を書いて」では一般論が出てきますが、「この文字起こしからこの 11 節を埋めて」ならレビュー担当が見慣れた形が出てきます。

3. 「述べられたこと」と「推測」を分けるよう明示的に指示する。たとえば、文字起こしにあるものだけを使う。裏付けとなる内容が無い節は、埋めずに「打ち合わせでは触れられていない」と書く。妥当だが言われていないものは前提として印を付ける。この一つの指示が、有用な初稿と負債との差のほとんどを作ります。

4. まず HLD のアウトライン、次に BOM を別々に生成する。狭い指示の 2 パスは、何もかも頼む 1 パスに勝ります。BOM のパスでは、声に出して言われなかった数量はすべて「未指定」と出力し、決して推測しないよう指示します。

5. 誰かに見せる前に、自分の記憶と突き合わせて読む。あなたはその場にいました。見るのは 2 点です。微妙に誤っている内容と、自信たっぷりに存在するが一度も語られていない内容。後者のほうが見つけにくいのは、まさによく書けているからです。

6. すべての「触れられていない」「未指定」を、番号付きの質問リストにする。これがこの作業全体で最も価値のある成果物です。次回打ち合わせの議題であり、具体的な質問リストは「ちゃんと聞いていた」証拠として顧客に読まれます。

7. アーキテクトにはドラフトとして、そう明記して渡す。有資格者が目を通すまで、文書には見える形で状態を——「AI 補助の初稿、未レビュー」と——付けておきます。典型的な事故は、ドラフトがメールのやり取りに紛れ込み、得ていない権威を帯びることです。

8. アーキテクトに修正させ、補わせ、責任を持たせる。彼らは内容を変え、誰も口にしなかった要件を足します。この種の設計に実際に何が要るかを知っているからです。その作業こそが設計です。それ以前はすべて、構造の付いた書き起こしにすぎません。

9. プロンプトとテンプレートを残し、改善する。2 件目は 1 件目よりずっと速くなります。再利用できる資産は出力ではなく指示のほうだからです。

AI が起草した HLD vs 認定アーキテクトの HLD vs 書面の設計が無い場合

AI 補助の初稿。数日ではなく数時間で、前提とスコープ外を丁寧に拾い、抜けを早期に可視化します。専門的な責任は一切負わず、設計が妥当かを判断できず、指示が無ければ推測を事実として提示します。正しい使い方は、アーキテクトの仕事への入力であって、その代替では決してありません。
認定アーキテクトの HLD。有資格者が、その規模・その建物・その予算で成立すると判断し、適切にサイジングし、名前を出しています。その責任こそが実際の製品です——顧客が設計を求めるとき買っているのはそれであり、納品時にベンダーが背負うのもそれです。希少な専門時間を消費するからこそ、書き起こしと構造化の部分を自動化する価値があります。
書面の設計が無い場合。誰もが認める以上によくあります。口頭の合意、メールの機器リスト、そして請求書。範囲についての最初の食い違いが起きるまでは回ります。起きた時点で指し示す文書は無く、より粘った側が勝ちます。

多くの会社にとって現実的な組み合わせは、前者を後者に流し込むことです。得られるのは安い設計ではなく、速い応答、よりよく記録された前提、そして体裁ではなく判断に時間を使うアーキテクトです。

初稿が積極的に誤解を招く場面

一度も言及されなかった制約は、文字起こしに存在しない。建物のシャフト容量、賃貸人の制限、顧客が「当然知っているはず」と思っていた規制要件——録音に無いのだから初稿にも無い。文書は完全に見えながら、設計を決定づけるものを欠いています。

でっち上げられた具体性が、典型的な失敗。専門的な文書を求められたモデルは、もっともらしい詳細を供給します。誰も話していない型番、黙って置いた前提から導かれたスイッチ台数。正しい部分とまったく同じ読み心地であることが、危険な理由です。

書き起こしの誤りは伝播する。自動書き起こしは技術用語と数字を日常的に聞き違え、「50」が「15」になると、完璧に読めて誤っている文が出来上がります。すべての数字は文字起こしではなく録音と突き合わせてください。

自信ある文章が、根拠の薄さを覆い隠す。誰かが「ダウンタイムはさすがに困る」と言ったのに、初稿が顧客は「99.9% の可用性を要求」と断定していれば、仕様が捏造されています。その数字はやがて SLA の議論に現れます。

背後にベンダーの責任が無い。文書の価値は、発行した組織がそれを裏書きする範囲までです。未レビューの AI ドラフトは、どれだけ見栄えがよくても誰にも何も約束しません。社内に留まる限り問題ありませんが、顧客が提案書として扱った瞬間に実害になります。

ここを外さない——文字起こしの顧客機密、文書の所有、そしていつ IT を呼ぶか

ヒアリングの文字起こしは機密だと前提する。実際に機密です。通常そこには顧客の正式名称、拠点、人数、現行インフラとその弱点、予算額、社内力学、そしてしばしば「あのシステムはずっとパッチを当てていない」という何気ない一言が含まれます。攻撃者にとって有用な文書であり、漏れれば気まずい文書です。

その文字起こしが実際にどのツールへ、どの条件で入るのかを把握する。個人向けアカウント、法人プラン、エンタープライズ導入では、データの保持や学習利用の可否が異なります。自社が使っている具体的なプランの条件を確認し、どのツールが顧客資料を受け取ってよいかを全社ルールとして定めてください。これはプロフェッショナルサービス企業で最も一般的な、統制されていない AI リスクであり、技術ではなくガバナンスの問題です。

判断ではなく既定として匿名化する。「アップロード前に顧客識別情報を外す」という常設ルールは納期の圧力に耐えますが、「気をつける」というルールは耐えません。

録音の保管場所と保持期間を決める。通話の録音と文字起こしは、既定では会議プラットフォームに無期限で積み上がります。顧客との契約が機密情報や資料の返却に触れているなら、これは適用範囲内です。

文書の中にドラフト状態を明記する。アーキテクトが承認するまで、AI 補助の初稿はページ上でそう名乗るべきです。この手法は「完成して見える初期文書」を生むため、バージョン管理が普段以上に重要になります。

レビューする人は、却下できる資格を持っていなければならない。この手法の価値は、有能な誰かが一節まるごと消す用意があるかどうかに完全に依存します。レビューが形式なら、起草の速さが買っているのは、悪い設計への速い経路です。

提案プロセスのどこに AI を置くか、指示テンプレートを書くこと、何をアップロードしてよいかのルールを定めることは AI+ サポートの仕事です。その下のツール、アクセス制御、データの取り扱いは通常のマネージド IT サポートです。そして自動化されない部分——コストを織り込んだベンダー中立の HLD を出す認定アーキテクト、納品を回す PMP または PRINCE2 のプロジェクトマネージャー、希望リストをリードタイム付きの実在する BOM に変えるサプライチェーンチーム——が当社の IT プロフェッショナルサービスです。他のプロジェクト文書も同じやり方で起草しているなら、ERP 本番移行の UAT スクリプトとカットオーバー手順書と締結前の IT サービス契約レビューが、同じ「AI が起草し、専門家が責任を持つ」型を扱っています。

よくある質問

認定アーキテクトの承認を置き換えられますか？

いいえ。そしてこの区別は形式ではありません。顧客が設計とともに買っているのは責任です。有資格者が、その規模・その建物・その予算で成立すると判断し、その会社が納品時に裏書きする。モデルはその責任を負えません。置き換わるのは、打ち合わせからアーキテクトのレビューまでの間にある、書き起こしと体裁づくりの数時間です。

通話の録音と文字起こしはその後どうなりますか？

会議プラットフォームと AI ツールの保持設定次第で、多くの会社はそれを一度も確認していません。録音は会議プラットフォームに残り、文字起こしはチャットツールにアップロードされ、コピーは誰かのダウンロードフォルダに落ち着きます。意識的に決めてください。録音をどこに置き、どれだけ保持し、どのツールが受け取ってよく、案件終了時にどうするか——特に顧客契約が機密情報に触れている場合は。

BOM に実際の価格は入りますか？

入れるべきではありませんし、そう依頼すべきでもありません。価格は数量契約、地域ごとの供給状況、為替、輸入関税、リードタイムに左右される商流の事実で、サプライチェーンのチーム側にあり、絶えず変動します。モデルがもっともらしい価格を出すとき、それは架空の価格です。架空の数字が顧客に届くリスクは重大です。出力は「範囲の定まった機器チェックリスト」として扱い、価格は調達が付けてください。

ChatGPT に「ネットワーク設計を書いて」と頼むのと何が違いますか？

まったく別物で、違いは出所です。設計を頼むのは、一般知識からもっともらしい汎用アーキテクチャを生成させることであり、顧客の建物・制約・予算とは切り離されています。この進め方はその逆です。文字起こしに無いものを足すことを明示的に禁じ、抜けは抜けとして印を付けることを求めます。設計者としてではなく、自分の一次資料に対する構造化ツールとして使っているのです。

文字起こしの品質が悪い場合は？

初稿も、見つけにくい形で悪くなります。だからこそ入力を直す価値があります。まともな会議プラットフォームの書き起こしを使い、明瞭に録音し、打ち合わせ中に数字を言い直す習慣をつけてください——「では 3 フロアで合計 50 台のアクセスポイントですね」——これは顧客への要件確認になり、同時に文字起こしに曖昧さの無い一行を残します。どの数字も、文書に入る前に音声と突き合わせてください。