【第4回】PM/PMO業務をAIで劇的に効率化する|WBS作成・進捗管理・リスク予測の実践術

システム開発・PM向けシリーズの第4回です。

前回の第3回「コーディングとテストを爆速化するAI活用術」では、実装・テスト工程でGitHub Copilot等のAIを活用し、コーディングの手数を減らして単体テストを自動化する手法を解説しました。

今回は、プロジェクトの成否を握る「プロジェクトマネジメント(PM / PMO業務)」に焦点を当てます。

  • WBS(作業分解構成図)をゼロから作るのに時間がかかる
  • 毎週の週次報告書や進捗レポートの作成で半日潰れる
  • プロジェクトの遅延リスクや課題の察知が後手に回ってしまう

こうしたPM/PMOの現場の悩みを、生成AIでどう解決し、マネジメントの精度とスピードを高めるのか。すぐに使えるプロンプトと、現場で失敗しないための実践ノウハウをあわせて解説します。

1. なぜPM/PMO業務こそAI活用のインパクトが大きいのか?

プロジェクトマネジメント業務は、一見すると「人間の判断や調整がすべて」と思われがちです。

しかし、PMO(プロジェクトマネジメントオフィス)の日々の業務を細かく分解してみると、実は多くの時間が「情報の収集・整理・構造化・ドキュメント化」というテキスト処理作業に費やされています。

  • 開発チームからの日報・進捗報告の集計
  • 課題管理表(Issue Log)の更新とカテゴリ分類
  • 役員・クライアント向けの週次サマリーレポート作成
  • 仕様変更に伴うWBSの修正・タスクの再抽出
  • 会議の議事録作成と決定事項・宿題の整理

生成AIは、まさにこの「非構造化データ(雑多な報告テキスト)を、構造化データ(整然としたレポートやタスク一覧)に変換すること」を最も得意としています。

PM/PMOが事務作業に忙殺されるのを防ぎ、本来注力すべき「人間同士の調整」「ステークホルダーとの交渉」「定性的なリスクへの事前手当て」に集中できる環境を、AIで作ることができるのです。

なお、上流工程で作成した要件定義書や設計書は、そのままWBS作成のインプットになります。要件定義・設計でのAI活用は第2回「要件定義と設計をAIで加速する」で詳しく解説しているので、あわせてご覧ください。

2. 実践①:仕様書・要件からの「WBS(作業分解構成図)」自動生成

プロジェクト立ち上げ時、最も労力を使う作業の一つがWBSの作成です。要件定義書やシステム概要を入力し、AIにタスク分解のたたき台を作らせます。

💡 使えるプロンプト:WBS初期ドラフトの生成

あなたはPMI(米国プロジェクトマネジメント協会)が発行するPMBOKガイドに精通したシニアPMです。
以下の【システム概要】をもとに、開発プロジェクトのWBS(作業分解構成図)を作成してください。

【制約条件】
1. 大項目(フェーズ:要件定義・設計・実装・テスト・移行・リリース)、中項目(機能/作業単位)、小項目(具体的なタスク)の3層構造で出力すること。
2. 各タスクには「想定工数(人日)」と「先行タスク(依存関係)」の目安を記載すること。
3. 各タスクの「完了条件(成果物)」を1行で記載すること。
4. 表形式(Markdownテーブル)で出力し、最後にCSV形式でもコードブロック内に出力すること(Excelにコピペできるようにするため)。
5. 一般的に見落とされやすいタスク(環境構築、データ移行、運用手順書作成、各種レビューなど)があれば明示すること。

【システム概要】
・顧客向け会員制ポータルサイトの刷新プロジェクト(Web+スマホ対応)
・主な機能:ユーザー認証、会員情報変更、マイページ、お知らせ配信、問い合わせフォーム
・開発期間:約4ヶ月、開発メンバー:5名

ゼロからWBSを作成すると半日〜1日かかることも珍しくありませんが、AIにドラフトを作らせれば、数分で「抜け漏れを確認しやすいタスク一覧のたたき台」が手に入ります。PMはこれをベースに、プロジェクト固有の事情を反映させる調整に集中できます。

WBSの考え方そのものを確認したい場合は、PMIが公開しているPMBOK Guide(PMI公式)も参考になります。

✅ AIが作ったWBSをレビューする3つのポイント

  1. 工数の妥当性:AIの工数は一般論です。チームのスキルや過去実績と照らし合わせ、担当者と必ず突き合わせましょう。
  2. プロジェクト固有タスクの漏れ:顧客独自の承認フロー、社内の品質ゲート、外部ベンダーとの調整などはAIには分かりません。
  3. 粒度の統一:小項目は「1タスク=数日以内で完了・進捗判定できる大きさ」を目安に揃えると、後の進捗管理が楽になります。

3. 実践②:日報・チャットログからの「週次進捗レポート」自動作成

開発メンバーから上がってくる日報や、チャットツール(Slack / Teams)のやり取りをまとめ、役員やクライアントへ提出する「週次報告書」を短時間で生成します。

💡 使えるプロンプト:週次レポートの構造化

以下の【今週の開発チーム日報メモ】を集計し、プロジェクトオーナー向けの週次進捗レポートを作成してください。

【出力フォーマット】
1. 今週のエグゼクティブサマリー(3行で全体の進捗状況を要約)
2. マイルストーン達成状況(予定通り / 遅延ありの判定と、その根拠)
3. 今週完了した主要な成果物・機能
4. 発生している課題(Issue)と対応方針(重要度:高・中・低で分類)
5. 来週の主な予定タスク
6. 意思決定が必要な事項(オーナーに判断を仰ぐもの)

【注意事項】
・日報に書かれていない事実を推測で補わないこと。不明点は「要確認」と明記すること。

【今週の開発チーム日報メモ】
(Slackのチャンネルログやメンバーからの日報テキストを貼り付け)

これにより、毎週数時間かけていた報告書作成作業を、確認・手直しを含めても大幅に短縮できます。特に「推測で補わない」「不明点は要確認と書く」という指示を入れておくと、AIがもっともらしい内容を書き足してしまう事故(ハルシネーション)を防ぎやすくなります。

定例会議の議事録から決定事項やToDoを自動抽出する方法は、ビジネス編の【第3回】会議の議事録作成が「ゼロ」に?文字起こしとタスク自動抽出の活用術で解説しています。議事録とレポートをセットで自動化すると、PMOの定型業務はさらに軽くなります。

4. 実践③:テキストからの「潜在的プロジェクトリスク」の事前察知

PMとして優秀な人ほど、「まだ表面化していないリスクの予兆」を早期に察知します。AIにチームのやり取りを読み込ませ、第三者視点でのリスク分析を行わせる手法です。

💡 使えるプロンプト:潜在リスクの洗い出し

あなたはリスクマネジメントに長けたPMOアドバイザーです。
以下の【チーム内の会話ログ・課題メモ】を分析し、今後プロジェクトを遅延させる可能性がある「潜在的なリスク」を洗い出してください。

【分析の観点】
1. 技術的リスク(未知の技術、外部API依存、仕様の未決定など)
2. リソース・コミュニケーションリスク(特定のメンバーへの負荷集中、仕様認識のズレなど)
3. スケジュールリスク(テスト工程の圧迫、レビュー待ちの滞留など)

各リスクについて「発生確率(高/中/低)」「想定される影響度」「PMが今すぐ打つべき予防策」を提示してください。
また、各リスクの根拠となったログの該当箇所も引用してください。

【チーム内の会話ログ・課題メモ】
(日々のやり取りや仕様変更のメモを貼り付け)

自分1人の視点では「まあ大丈夫だろう」と見過ごしていた違和感や、特定工程への負担集中をAIが客観的に指摘してくれるため、炎上を未然に防ぐ「先手管理」が可能になります。根拠となるログを引用させることで、AIの指摘が妥当かどうかをPM自身がすぐに検証できます。

おすすめは、毎週同じプロンプトで「定点観測」することです。前週のリスク一覧も一緒に渡して「新たに増えたリスク」「解消されたリスク」を比較させると、プロジェクトの健康状態の変化が一目で分かります。

5. PM/PMO業務へのAI導入は「小さく始める」が鉄則

いきなりすべての管理業務をAI化しようとすると、ルール整備が追いつかず現場が混乱します。次の順番で段階的に広げるのがおすすめです。

  1. ステップ1:個人の下書き作業から
    まずはPM自身の週次レポートやWBSのたたき台作成など、最終的に人がチェックする作業から始めます。
  2. ステップ2:プロンプトのテンプレート化
    効果が出たプロンプトをチーム共有のテンプレートにし、誰が使っても同じ品質のアウトプットが出るようにします。
  3. ステップ3:ツール連携・自動化
    チャットツールや課題管理ツールと連携し、日報の収集からレポート生成までを半自動化します。

ステップ3のような既存システムとの連携は、セキュリティや権限設計も含めた検討が必要になります。この点は次回(第5回)で詳しく取り上げます。

6. PM/PMO業務でAIを活用する際のガバナンスと注意点

プロジェクト管理でAIを安全に運用するためには、以下のガバナンス体制を敷くことが重要です。

チェック項目注意すべきリスク現場での運用ルール・防衛策
契約・機密情報の保護クライアントとの契約内容や未公開のシステム仕様が、AIの学習データとして利用されるリスク入力データを学習に利用しない設定・契約(法人向けプランやオプトアウト設定)のAIツールを使用する。顧客との秘密保持契約(NDA)でAI利用が許容されているかも確認する。
個人情報の取り扱い日報やチャットログに含まれる氏名・連絡先などの個人情報の入力必要に応じて氏名をイニシャルや役割名(「担当A」など)に置き換えてから入力する。
スケジュールの鵜呑み防止AIが出した想定工数(人日)は一般的な目安であり、チームのスキルレベルを考慮していないAIが出したWBS工数は必ず担当エンジニアと突き合わせ、「実現可能性」を確認する。
人間関係・評価への非適用メンバーの能力評価や批判的な意見をAIに判定させることによる、チームのモチベーション低下AIの役割は「タスクとリスクの整理」に限定し、ピープルマネジメント(対話)はPMが直接行う。

社内ルールを整備する際は、総務省・経済産業省が公表している「AI事業者ガイドライン」(経済産業省)も参考になります。AIを「利用する側」の事業者に求められる考え方も整理されています。

7. よくある質問(FAQ)

Q. AIが作ったWBSや報告書をそのまま提出しても大丈夫ですか?

A. おすすめしません。AIの出力はあくまで「たたき台」です。工数や事実関係は必ずPMや担当者が確認し、プロジェクト固有の事情を反映させたうえで提出しましょう。

Q. どのAIツールを使えばよいですか?

A. 本記事のプロンプトは、ChatGPT・Claude・Geminiなど主要な生成AIで利用できます。ツール選定では性能以上に、入力データが学習に使われない設定・契約になっているかを優先して確認してください。

Q. 小規模なチームでも効果はありますか?

A. あります。むしろPMが開発も兼務するような少人数チームほど、報告書作成などの定型作業をAIに任せる効果は大きくなります。

8. まとめ:PM/PMOは「作業者」から「真のリーダー」へ

PM/PMOにおけるAI活用の本質は、報告書作成やWBS調整といった「作業」を自動化し、PMが本来行うべき「プロジェクトの意思決定」「メンバーの伴走」「ステークホルダーとの交渉」に時間と情熱を注げるようにすることです。

  • WBS作成・日報集計・レポート作成 ➔ AIがたたき台を数分で作成
  • PM/PMO ➔ 確認・判断と、人間にしかできない「交渉・決断・チームのモチベーション管理」に専念

この分業体制を確立し、炎上しない強いプロジェクトチームを作っていきましょう。

WAI SYSTEMSでは、ITコンサルティングや業務システム開発を通じて、プロジェクト管理へのAI導入や業務効率化をご支援しています。「自社のプロジェクトにどう取り入れればよいか分からない」という段階でも、お気軽にお問い合わせください。

次回(第5回)は、アーキテクチャ・技術基盤がテーマです。「既存システムやWeb・会計ツール等とAIを安全に繋ぐアーキテクチャ・連携ポイント」について詳しく解説します。

シリーズB(システム開発・PM向け)バックナンバー

まだExcelで大丈夫?業務システム化を検討すべき5つのサイン

はじめに

「顧客リストも、売上も、在庫も、全部Excelで管理している」

中小企業や小規模事業者では、このような会社がまだまだ多いのではないでしょうか。Excelは誰でも使えて、追加費用もかからず、自由に表を作れる優れたツールです。創業期や従業員が少ないうちは、Excelで十分というケースもたくさんあります。

しかし、事業が成長して扱うデータや関わる人が増えてくると、Excelでの管理は少しずつ無理が出てきます。厄介なのは、毎日の作業の中で「少し面倒だな」と感じる程度の変化なので、限界に気づきにくいことです。

本記事では、業務システム化を検討すべき5つのサインと、Excelからの移行で失敗しないためのポイントを解説します。

業務システム化を検討すべき5つのサイン

サイン1:ファイルが重く、開くたびに待たされる

何年分ものデータを1つのファイルに追加し続けると、ファイルを開くだけで数十秒かかったり、保存のたびに固まったりするようになります。関数やリンクが増えると計算も遅くなり、最悪の場合はファイルが壊れて開けなくなることもあります。毎日の数十秒の待ち時間も、社員全員で積み重なれば大きなロスです。

参考:Excel の仕様と制限(Microsoft サポート)

サイン2:同時編集による上書き事故が起きる

共有フォルダのExcelを複数人で使っていると、「誰かが開いているので編集できない」「Aさんの入力がBさんの保存で消えた」といったトラブルが起きがちです。「最新版_修正_田中.xlsx」のように似たファイルが増えて、どれが正しいのかわからなくなるのも典型的な症状です。

サイン3:作った人しか触れない(属人化)

複雑な関数やマクロを組んだ担当者が異動・退職したとたん、誰も直せなくなる。これはExcel管理で最も怖いリスクの一つです。「このセルは触らないで」という注意書きが増えてきたら、仕組みが一人の頭の中にしかない状態になっています。

サイン4:転記ミスや入力ミスが減らない

見積書から受注表へ、受注表から請求書へと、同じ情報を何度も手で写していませんか?転記の回数が多いほどミスは起きやすくなります。Excelは入力のチェックが弱いため、全角と半角の混在や日付の打ち間違いもそのまま残り、後で集計が合わない原因になります。

サイン5:月末の集計や報告書作りに何時間もかかる

複数のファイルからデータをコピーして貼り合わせ、手作業で集計表を作る。この作業が毎月何時間もかかっているなら要注意です。集計に時間がかかると、経営判断に必要な数字が出てくるのも遅くなり、「先月の状況が今月半ばにやっとわかる」という状態になってしまいます。

あなたの会社は大丈夫?セルフチェックリスト

当てはまる項目の数を数えてみてください。

  • ☐ ファイルを開く・保存するのに時間がかかる
  • ☐ 「最新版」「修正版」など似た名前のファイルが複数ある
  • ☐ 同時に編集できず、他の人が閉じるのを待つことがある
  • ☐ 特定の人しか中身を理解していないファイルがある
  • ☐ 同じ情報を複数のファイルに入力している
  • ☐ 入力ミスや転記ミスが原因のトラブルが月に1回以上ある
  • ☐ 月末・月初の集計作業に半日以上かかる
  • ☐ 外出先や自宅から最新データを確認できない

0〜2個なら、今のExcel運用を工夫するだけで十分かもしれません。3〜5個なら、一部の業務からシステム化を検討する価値があります。6個以上なら、Excelの限界による損失がすでに出ている可能性が高い状態です。

「システム化」には3つの選択肢がある

システム化と聞くと、大がかりで高額な開発をイメージするかもしれません。しかし実際には、会社の規模や業務に合わせていくつかの選択肢があります。

Excelを改善して続けるクラウドサービスを使う業務システムを開発する
初期費用ほぼかからない低い必要
月々の費用ほぼかからない利用人数に応じた月額料金保守費用
自社業務への合わせやすさ高いサービスの仕様に業務を合わせる必要がある自社の業務に合わせて作れる
向いているケースサインが少なく、使う人も少ない会計・勤怠など、どの会社でも共通の業務自社独自の業務フローや、複数業務のデータ連携

会計や勤怠管理のように、どの会社でもやり方がほぼ同じ業務は、既製のクラウドサービスを使うのが効率的です。一方で、受注から製造・出荷までの流れや、業界特有の管理項目など、自社ならではの業務はクラウドサービスでは対応しきれないことがあります。そうした場合に、業務システムの開発が力を発揮します。

なお、クラウドサービスなどのITツール導入には、国の補助金を活用できる場合があります。2026年度からは、従来の「IT導入補助金」が「デジタル化・AI導入補助金」に名称を変えて実施されています。対象となるツールや公募時期は年度ごとに変わるため、最新情報は公式サイトで確認しましょう。

参考:デジタル化・AI導入補助金2026の公募要領を公開(中小企業庁 ミラサポplus)

システム化で失敗しないための3つのポイント

1. いきなり全部をシステム化しない

最初から全業務をまとめて置き換えようとすると、費用も期間も膨らみ、現場も混乱します。まずは「一番困っている業務」や「一番時間がかかっている業務」を1つ選び、小さく始めるのが成功の近道です。効果を確かめてから、範囲を広げていけば十分です。

2. 今のExcelを「設計書」として活かす

長年使ってきたExcelには、どんな項目を管理しているか、どんな計算をしているかといった業務のノウハウが詰まっています。これは新しいシステムを作るうえで最高の資料です。既存のデータもそのまま移行できるよう、最初から計画に入れておきましょう。

3. 実際に使う人の声を聞く

システムは、毎日入力する現場の人が使いやすくなければ定着しません。経営者だけで決めずに、実際に作業している人に「どこが面倒か」「何が困っているか」を聞くことが大切です。現場の小さな不満の中に、本当に解決すべき課題が隠れています。

まとめ:Excelの「限界サイン」は改善のチャンス

Excelは便利なツールですが、事業の成長とともに次のようなサインが現れてきます。

  1. ファイルが重く、開くたびに待たされる
  2. 同時編集による上書き事故が起きる
  3. 作った人しか触れない
  4. 転記ミスや入力ミスが減らない
  5. 月末の集計や報告書作りに何時間もかかる

これらのサインは、裏を返せば「業務をもっと効率化できる余地がある」というメッセージでもあります。すべてを一度に変える必要はありません。一番困っている業務から、小さく始めてみましょう。

WAI SYSTEMSでは、25年以上の業務系システム開発の経験を活かし、中小企業の業務に合わせたシステムづくりをお手伝いしています。「このExcel、システムにできる?」「うちの規模でも意味がある?」といった段階からでも、お気軽にご相談ください。

IT化の進め方全体について知りたい方は、こちらの記事もあわせてご覧ください。

『何から始めればいい?』中小企業のIT化・業務効率化を成功させる3つのステップ

【第3回】コーディングとテストを爆速化するAI活用術|GitHub Copilot・単体テスト自動化

システム開発・PM向けシリーズの第3回です。シリーズの全体像は第1回「開発現場における生成AIの現在地」をご覧ください。

前回の第2回「要件定義と設計をAIで加速する」では、上流工程(要件定義・設計)においてAIを「思考のパートナー」として活用し、仕様の抜け漏れや手戻りを防ぐノウハウについて解説しました。

今回は、現場のエンジニアにとって最も関心が高い「実装(コーディング)およびテスト(品質保証)」のフェーズにスポットを当てます。

GitHub CopilotやCursor、Claudeといった開発アシスタントツールを現場に組み込み、開発スピードを大きく高めつつ、潜在的なバグや脆弱性をどう防ぐのか。プロの現場で実践されているリアルな活用技術を解説します。

1. 実装フェーズにおける最大の敵「ボイラープレートコード」の排除

開発現場において、エンジニアの貴重な時間と集中力を最も奪っているのは何でしょうか?

新しいアルゴリズムの考案でも、高度な設計でもありません。「書くことが決まっている定型コード(ボイラープレートコード)」のタイピング作業です。

  • データベースのCRUD(作成・読み出し・更新・削除)を処理する共通関数
  • Web APIの型定義(TypeScriptのInterfaceやDTOクラス)
  • 画面入力値のバリデーション(チェック)ロジック
  • 例外処理(Try-Catch)やログ出力の定型文

GitHub Copilotなどのインライン補完型AIは、ファイル内のコンテキスト(前後のコードやコメント)を解析し、エンジニアが数文字打った瞬間に「次に書きたいコード」を予測して先回り提示してくれます。

これにより、タイピングの手数が激減するだけでなく、「構文を調べるためにブラウザとエディタを行き来する時間」も大幅に削減され、エンジニアは高度な集中状態(フロー状態)を維持したままコーディングに没頭できるようになります。

2. 実践①:コメント駆動開発(Comment-Driven Development)

AIコーディングの成果を最大化する強力な手法が「コメント駆動開発」です。

コードを書き始める前に、まず「どのような処理を行いたいか」を日本語のコメントとして丁寧に記述し、それにAIへコードを生成させるアプローチです。

💡 実践例(TypeScriptのケース)

以下のようにエディタ上で日本語コメントを記述します。

// 【関数名】calculateDiscountedPrice
// 【概要】商品の税抜価格と会員ランクから最終支払金額(税込)を計算する
// 【ルール】
// 1. 会員ランクが"GOLD"の場合は20%引き、"SILVER"の場合は10%引き、それ以外は割引なし
// 2. 割引後の金額に消費税10%を加算する(端数は切り捨て)
// 3. 入力価格が0以下の場合はRangeErrorをスローする
function calculateDiscountedPrice(price: number, memberRank: string): number {
  // ここでTabキーを押すと、AIが上記の仕様に沿ったコードを補完生成する
}

「AIにどのような前提でコードを書かせるか」をコメントとして明記するため、設計意図がコード上に自然と残り、後から他のエンジニアが読んでも理解しやすいコードになります。もちろん、生成されたコードがコメントの仕様どおりに動くかは、次章の単体テストで必ず確認しましょう。

3. 実践②:単体テスト(Unit Test)自動化とエッジケースの網羅

実装以上に時間がかかり、プロジェクト終盤でスケジュールを圧迫しがちなのが「テストコード(単体テスト)の作成」です。

「テストを書く重要性は分かっているが、工数が足りずに疎かになってしまう…」という現場の悩みに対し、AIは最強の威力を発揮します。

💡 使えるプロンプト・指示手順

作成した実装コードを選択し、AIチャットやプロンプトで以下のように指示します(例はJavaのJUnit 5を想定しています。Jest / PyTestを使う場合は、@DisplayNameやMockitoの部分を各フレームワークの書き方に置き換えてください)。

あなたは品質保証(QA)に厳しいシニアテストエンジニアです。
以下の【実装コード】に対する、JUnit 5(またはJest / PyTest)を用いた単体テストクラスを作成してください。

【テスト作成の制約条件】
1. 正常系だけでなく、以下の異常系・エッジケース(境界値)のテストメソッドを必ず網羅すること。
   - 入力値がnull、空文字、または定義外の文字列の場合
   - 数値パラメータが0、負の数、または上限最大値(MAX_VALUE)の場合
2. 各テストメソッドには、何を検証しているかが一目でわかる日本語のテスト名(@DisplayName等)を付与すること。
3. モック(Mockito等)が必要な外部依存処理がある場合は、適切にモック化すること。

【実装コード】
(対象のコードを貼り付け)

この指示を行うことで、人間が頭を悩ませながら洗い出していたテストケースが短時間で揃い、テストカバレッジ(網羅率)80%〜90%といった目標値も達成しやすくなります。
ただし、AIは「今の実装の動き」をそのまま正解としてテストを書いてしまうことがあります。期待値が本来の仕様と合っているかは、必ず人間がレビューしてください。

4. 実践③:レガシーコードの解説とリファクタリング

「過去の担当者が残した、コメントも仕様書もない複雑な長文コード」の修正は、エンジニアにとって最もストレスがかかる作業です。AIはこうしたレガシーコードの解読にも威力を発揮します。

💡 解読とリファクタリングのプロンプト

以下の【レガシーコード】を解析し、以下の2点を行ってください。

1. 【コードの解説】
   このコードが何を行っているのか、処理の流れをステップ・バイ・ステップで分かりやすい日本語で解説してください。
2. 【リファクタリング案】
   - 可読性と保守性を高めるため、関数を適切に分割したコードを提示してください。
   - 処理のパフォーマンス(計算量)やメモリ効率を改善できる点があれば修正してください。
   - セキュリティ上のリスク(例:SQLインジェクションやメモリリーク等)がないか評価してください。

【レガシーコード】
(解読したい古いコードを貼り付け)

5. AIコーディングにおける「3大リスク」と防衛策

AIを活用した実装・テストは開発速度を劇的に高めますが、無条件に信じ込むと深刻な事故につながります(AIの出力を鵜呑みにしてしまう心理については第0回でも解説しています)。プロとして以下の3大リスクと対策を厳守してください。

リスク要因潜んでいる危険性現場での防衛策(ガバナンス)
① 脆弱性コードの混入AIは過去の古い不完全なコードも学習しているため、古い暗号化方式や脆弱な処理を出力することがある。SonarQubeなどの静的コード解析ツールによる自動レビューをCI/CDに組み込み、人間が最終確認する。
② ライセンス汚染パブリックリポジトリのコードと酷似したコードが自動生成され、著作権侵害(GPL等)になるリスク。AIツールの管理者設定で「パブリックコードに一致する提案(Suggestions matching public code)」を「ブロック」に設定する(参考:GitHub Docs)。
③ ブラックボックス化コードの仕組みを理解しないままコピペで組み込み、障害発生時に誰も修正できなくなる。コードレビュー時に「AIが作った理由」を説明できないコードはマージしない文化を徹底する。

6. まとめ:AIは開発チームの「最強のペアプログラマー」

実装・テストフェーズにおけるAIの正しい位置づけは、開発者の代わりにすべてを行う魔法ではなく、「24時間いつでも隣でコードを補完し、テストケースを提案してくれる超優秀なペアプログラマー」です。

  • 定型コードの作成や単体テスト作成 ➔ AIに任せて爆速化
  • アーキテクチャ設計・セキュリティ検証・レビュー ➔ 人間が全責任を持って判断

この明確な役割分担をチーム内で確立することこそが、開発速度とシステム品質を最高の次元で両立させる鍵となります。

次回(第4回)は、プロジェクト管理の現場に踏み込みます。「PM/PMO業務におけるAIアシスタントの具体的な使いどころと進捗管理の自動化」について詳しく解説します!

WAI SYSTEMSでは、AI活用を前提としたシステム開発や、開発プロセス改善のコンサルティングも承っています。「自社の開発現場にどう取り入れればいいか分からない」という方は、お気軽にお問い合わせください。

【第2回】要件定義と設計をAIで加速する|仕様漏れを防ぐプロンプトとドキュメントレビュー術

WAI SYSTEMSのブログ連載、シリーズB(IT・システム開発・プロジェクト管理向け)の第2回です。

前回(第1回)では、要件定義・実装・PMOといった開発現場の各フェーズで、生成AIがどのように使われ始めているのか、その「現在地」を整理しました。今回からは、いよいよ具体的な開発フェーズに踏み込んでいきます。

システム開発において、手戻り(手直し)のコストが最も高くつくのはどのフェーズでしょうか? 言うまでもなく、「要件定義」および「基本設計」のフェーズです。

実装(コーディング)段階やテスト段階で仕様の抜け漏れや矛盾が発覚すると、手戻り工数は数倍〜数十倍に膨れ上がります。リリース後に発覚すれば、その影響は顧客の業務や信頼にまで及びます。

今回は、生成AI(LLM)を活用して「要件定義・設計フェーズにおける仕様漏れを防ぎ、ドキュメント作成とレビューを高速化・高品質化する手法」について、そのまま使えるプロンプト例を交えて解説します。

1. 上流工程におけるAIの役割は「壁打ち相手」と「抜け漏れ検知器」

要件定義や設計において、AIに「仕様書を全部書いて」と丸投げするのは間違いです。顧客の泥臭い業務プロセスや、言葉になっていない本当のニーズは、AIには分からないからです。

上流工程におけるAIの真の価値は、以下の2点にあります。

  1. 思考の壁打ち相手(ブレストパートナー): 提示した要求に対して「他に考慮すべきケースはないか?」と問いを立てさせる
  2. 抜け漏れ検知器(ネガティブチェック): 人間が作成した仕様書に対して、エッジケースや例外処理の欠落を指摘させる

エンジニアやPMが頭の中で考えている設計案をAIにぶつけ、AIに「悪魔の弁護人(あえて反対意見や欠点を指摘する役割)」になってもらうことで、設計の品質を大きく高めることができます。

💡 使えるプロンプト例:悪魔の弁護人

あなたは経験豊富なシステムアーキテクトであり、今回は「悪魔の弁護人」役です。
以下の【設計方針】に対して、あえて批判的な立場から問題点を指摘してください。

【指摘してほしい観点】
1. 想定していない利用パターン・例外ケース
2. 将来の機能追加や利用者増加で破綻しそうな点
3. 運用・保守担当者が困りそうな点

【出力形式】
指摘ごとに「懸念点」「起こりうる事象」「確認すべき質問」を記載すること

【設計方針】
(検討中の設計方針を箇条書きで貼り付け)

ポイントは「確認すべき質問」まで出力させることです。AIの指摘をそのまま採用するのではなく、顧客や有識者に確認すべき論点のリストとして活用することで、打ち合わせの質が上がります。

2. 実践①:ヒアリングメモからの「要件定義・機能一覧」構造化

顧客との打ち合わせで取った雑多なヒアリングメモから、要件定義の初期ドラフトを作成する手法です。

💡 使えるプロンプト例:要件の構造化

あなたはITコンサルタントおよび上流工程を担当するシステムエンジニアです。
以下の【ヒアリングメモ】をもとに、システムに必要な機能要件を構造化してリストアップしてください。

【制約条件】
1. 大項目(カテゴリ)、中項目(機能名)、詳細説明、想定されるユーザー権限の表形式で出力すること
2. メモに明記されていないが、一般的なECシステムとして必要不可欠と思われる機能(例:パスワードリセット、ログアウト等)があれば「推測・提案」として別欄に記載すること
3. メモの内容が曖昧で判断できない点は「未決事項」として最後に一覧化すること

【ヒアリングメモ】
(打ち合わせのテキストメモや文字起こしデータを貼り付け)

これにより、手作業で1時間以上かかる機能一覧表の骨組みが数秒〜数十秒で完成し、さらに「提案すべき隠れた要件」まで浮き彫りになります。

出力後に必ずやるべき「ひと手間」

  • 「推測・提案」欄は顧客確認用に分ける: AIの推測が混ざったまま要件として確定させないよう、確認待ちの項目として明確に区別します。
  • 「未決事項」は次回打ち合わせのアジェンダにする: 曖昧な点がリスト化されるため、次のヒアリングで何を聞くべきかが明確になります。
  • 業務用語の定義を揃える: 「顧客」「会員」「ユーザー」など、同じ意味の言葉がばらついていないかを確認し、用語集として整理しておくと後工程の誤解を防げます。

3. 実践②:非機能要件・セキュリティ要件の抜け漏れチェック

要件定義で最も見落とされがちなのが、パフォーマンス、セキュリティ、障害運用などの「非機能要件」です。顧客からは「普通に動けばいい」「セキュリティはしっかり」といった抽象的な要望しか出てこないことが多く、具体化は開発側の役割になります。

そこで、IPA(情報処理推進機構)が公開している非機能要求グレードや、Webアプリケーションの代表的なセキュリティリスクをまとめたOWASP Top 10といった、公的・業界標準の枠組みを観点としてAIに与えるのが効果的です。

💡 使えるプロンプト例:非機能要件のレビュー

以下の【機能概要】を持つWebシステムを構築予定です。
IPAの非機能要求グレードおよび一般的なセキュリティ基準(OWASP Top 10)に基づき、考慮すべき非機能要件と潜在的なリスクをリストアップしてください。

【機能概要】
・会員数:約10万人、月間PV:50万PVの会員制情報配信サイト
・決済機能(クレジットカード・PayPay連携)あり
・管理画面から大量の画像・PDFを一括アップロードする機能あり

【チェックしてほしい観点】
1. セキュリティ(認証、認可、データ暗号化)
2. パフォーマンス・拡張性(スパイクアクセス、ファイル容量)
3. 運用・障害対策(バックアップ、ログ保持期間)

【出力形式】
観点ごとに「要件項目」「推奨される目標値・対策」「顧客に確認すべき事項」を表形式で出力すること

このプロンプトを実行するだけで、インフラ設計やセキュリティ設計で考慮すべきチェックリストの叩き台がすぐに手に入ります。

ただし、AIが提示する「推奨される目標値」(稼働率99.9%、RPO 24時間など)はあくまで一般論です。目標値を上げるほどインフラ費用や運用コストは増えるため、最終的な数値は顧客の予算や業務への影響を踏まえて合意する必要があります。

4. 実践③:設計書・仕様書のAIレビュー(矛盾・曖昧表現の検出)

作成した要件定義書や基本設計書のレビューも、AIが得意とする領域です。人間のレビューは「書かれていること」の確認に偏りがちですが、AIには「書かれていないこと」「記述同士で食い違っていること」を機械的に洗い出させることができます。

💡 使えるプロンプト例:仕様書のセルフレビュー

あなたは品質保証(QA)担当のシニアエンジニアです。
以下の【仕様書】をレビューし、問題点を指摘してください。

【レビュー観点】
1. 矛盾:記述同士で食い違っている箇所
2. 曖昧表現:「適宜」「なるべく」「等」「速やかに」など、解釈が分かれる表現
3. 例外処理の欠落:入力エラー、タイムアウト、二重送信、権限不足時の挙動が未定義の箇所
4. テスト不能な記述:合否判定ができない(数値や条件がない)記述

【出力形式】
「該当箇所(章・項番)」「指摘内容」「修正案」の表形式で出力すること

【仕様書】
(レビュー対象の仕様書テキストを貼り付け)

特に「曖昧表現」と「テスト不能な記述」の検出は効果が大きく、後工程のテスト設計を楽にしてくれます。たとえば「検索結果は速やかに表示する」という記述は、「検索結果は3秒以内に表示する(データ件数10万件時)」のように、検証可能な形に書き換えるきっかけになります。

なお、AIレビューは人間のレビューを置き換えるものではなく、人間がレビューする前の「一次チェック」として位置付けるのがおすすめです。形式的な指摘をAIが先に潰しておくことで、レビュー会議では業務ロジックや設計判断といった本質的な議論に時間を使えるようになります。

5. 実践④:Mermaid / PlantUMLを活用した「図解(UML)」の自動生成

設計書に必要な「シーケンス図」や「ER図(エンティティ・リレーションシップ図)」、「状態遷移図」も、AIを使えばテキストからすぐにコード化できます。テキストで図を記述できるMermaidやPlantUMLといった記法を使います。

例えば、ChatGPTやClaudeに以下のように指示します。

プロンプト: 「ユーザーがログインし、2段階認証を経てマイページを表示するまでの処理フローを、Mermaid.jsのシーケンス図コードで出力してください。」

すると、次のようなコードが出力されます(一例)。

sequenceDiagram
    actor User as ユーザー
    participant Web as Webアプリ
    participant Auth as 認証サーバー
    User->>Web: ID・パスワードを入力
    Web->>Auth: 認証リクエスト
    Auth-->>Web: 認証OK(2段階認証が必要)
    Web-->>User: ワンタイムコード入力画面
    User->>Web: ワンタイムコードを入力
    Web->>Auth: コード検証
    Auth-->>Web: 検証OK
    Web-->>User: マイページを表示
Mermaidで描画したログイン処理のシーケンス図。登場するのはユーザー、Webアプリ、認証サーバーの3者。ユーザーがID・パスワードを入力すると、Webアプリが認証サーバーに認証をリクエストし、認証OK(2段階認証が必要)の応答を受けてワンタイムコード入力画面を表示する。ユーザーがワンタイムコードを入力すると、Webアプリが認証サーバーでコードを検証し、検証OKならマイページを表示する。
上記のMermaidコードを描画した結果

生成されたコードをNotionやGitHub、Mermaid対応のMarkdownエディタに貼り付けるだけで、シーケンス図が描画されます。図形ツールで矢印を1本ずつ引く作業から解放されるうえ、図がテキストで管理されるため、Gitでの差分管理や修正も容易になります。

さらに一歩進めて、「このシーケンス図に、認証失敗が3回続いた場合とワンタイムコードの有効期限切れの場合の分岐を追加して」と依頼すれば、異常系フローの考慮漏れチェックにも使えます。

6. 上流工程でAIを使う際のガバナンスと注意点

要件定義・設計フェーズでAIを活用する際は、以下のリスク管理が必須です。

  • 顧客の機密情報・個人情報のマスキング: ヒアリングメモをAIに入力する際は、顧客の社名、担当者名、具体的な売上データやパスワード情報などを「A社」「〇〇様」といったダミー文字に置き換えてから投入してください。
  • 入力データが学習に使われない環境を使う: 法人向けプランやAPI経由の利用など、入力内容がAIの学習に利用されない設定・契約になっているツールを選びましょう。個人情報の取り扱いについては、個人情報保護委員会の「生成AIサービスの利用に関する注意喚起等について」も参考になります。
  • 「AIの提案」をそのまま顧客要件にしない: AIが提示した「あった方が良い機能」を安易に要件に盛り込むと、スコープクリープ(要件の際限ない肥大化)につながります。必ず「今回のフェーズの予算・納期に収まるか」を人間が判断してください。
  • AIの出力を鵜呑みにしない: AIはもっともらしい誤り(ハルシネーション)を出力することがあります。法令や外部サービスの仕様に関わる記述は、必ず一次情報で裏付けを取ってください。

AIに入力してよい情報の線引きについては、第1回のガバナンスの章もあわせてご覧ください。また、なぜ人はAIの回答を信じてしまうのか、という根本的な話は【第0回】40年前の「コンピュータ占い」から何も変わっていない説で取り上げています。

7. まとめ:上流工程の品質向上こそが、最大のコスト削減

システム開発における最大のコスト削減は、コーディングを速くすることではなく、「設計の不備による手戻りを限りなくゼロに近づけること」です。

今回ご紹介した活用法を振り返ると、次のとおりです。

  • 悪魔の弁護人として、設計方針の弱点と確認すべき質問を洗い出す
  • ヒアリングメモから機能一覧と未決事項を構造化する
  • 非機能要求グレードやOWASPを観点に、非機能要件の抜け漏れをチェックする
  • 仕様書の矛盾・曖昧表現・テスト不能な記述を一次チェックする
  • シーケンス図などのUMLをテキストから生成し、異常系の検討にも活用する

要件定義や設計の段階でAIを「思考のパートナー」として活用し、あらゆる角度から抜け漏れや矛盾をチェックしておくこと。これこそが、納期の遵守と高品質なシステム構築を実現する最短ルートです。

次回(第3回)は、エンジニアの関心が最も高い「実装・テスト編」です。「GitHub CopilotなどのAIを活用したコーディング補助と、品質を高めるテスト自動化」について詳しく解説します!

WAI SYSTEMSでは、要件定義からのシステム開発や、AI活用を含めたITコンサルティングのご相談を承っています。「要件がまとまっていないけれど、まずは相談したい」という段階でもお気軽にお問い合わせください。

関連記事

【第1回】開発現場における生成AIの現在地|要件定義・実装・PMOはどう変わるか

WAI SYSTEMSのブログ連載、シリーズB(IT・システム開発・プロジェクト管理向け)の第1回です。

昨今、GitHub CopilotやChatGPT、Claude、Cursorといった生成AIツールや開発アシスタントが、システム開発の現場に爆発的な勢いで浸透しています。

「AIがコードを自動生成する時代、エンジニアの仕事はなくなるのか?」 「PMやPMO(プロジェクトマネジメントオフィス)の業務はAIでどう変わるのか?」 「実際の開発現場で、AIはどこまで使えて、どこからが危険なのか?」

今回は、GoogleおよびIBMのAI認定資格で得た最新のAIアーキテクチャや開発手法の理論と、20年以上にわたるシステム開発・プロジェクトマネジメントの泥臭い現場経験をもとに、「システム開発現場における生成AIのリアルな現在地」を解剖していきます。

1. 開発ライフサイクル(SDLC)におけるAIの貢献度

従来のウォーターフォール開発やアジャイル開発におけるソフトウェア開発ライフサイクル(SDLC)において、現在の生成AIはどのフェーズでどの程度のパフォーマンスを発揮するのでしょうか?

各工程におけるAIの現実的な貢献度(省力化・加速化の度合い)を整理すると、以下のようになります。

【要件定義・基本設計】 貢献度:★★260☆(約60%省力化)
  └ アイデア出し、仕様の抜け漏れチェック、非機能要件の洗い出し

【詳細設計・構造化】   貢献度:★★270☆(約70%省力化)
  └ DB設計案の作成、API仕様書案の自動生成、シーケンス図コード(PlantUML)化

【コーディング・実装】 貢献度:★★280☆(約80%省力化)
  └ ボイラープレートコード生成、関数の実装、リファクタリング、型定義

【テスト・品質保証】   貢献度:★★270☆(約70%省力化)
  └ 単体テスト(Unit Test)自動生成、境界値・エッジケースの洗い出し

【保守運用・調査】     貢献度:★★280☆(約80%省力化)
  └ エラーログの解析、レガシーコードの解読、他言語への移植

【PM / PMO管理】       貢献度:★★260☆(約60%省力化)
  └ 議事録からのタスク抽出、WBS原案作成、進捗報告書の構造化

一見すると、「もうすべての工程でAIに任せれば、人間はいらないのでは?」と思えるかもしれません。 しかし、現場の第一線でシステムを構築しているエンジニアやPMならお気づきの通り、ここに非常に大きな罠(落とし穴)が存在します。

2. 「80%の爆速化」と「残り20%の品質保証」の壁

AIを活用すると、V1(初版)のコードや仕様書ドラフトを作成するスピードは圧倒的に速くなります。これまで半日かかっていた関数の実装や、小一時間悩んでいた正規表現、APIのパラメータ設計などが、わずか数秒〜数分で出力されます。

開発のスピード感は、間違いなく従来の数倍〜数十倍に加速しています。

しかし、ここで現場のプロとして直面するのが「ハルシネーション(嘘や知ったかぶり)」と「プロジェクト特有のコンテキスト(文脈)理解の欠如」です。

AIは、過去のパブリックな学習データから「確率的に最もそれっぽいコード」を生成しているに過ぎません。そのため、以下のようなプロジェクト固有の事情を完全には考慮できません。

  • 「自社システムのDB設計における特有の制約ルール」
  • 「非同期処理における潜在的な競合状態(レースコンディション)」
  • 「特定のミドルウェアやライブラリのバージョン依存による非互換」
  • 「業務ロジックにおける例外的なイレギュラー運用」

生成されたコードが一見綺麗に動き、テストが通っているように見えても、本番環境にデプロイした途端に高負荷で落ちたり、特定の条件下で深刻なセキュリティホール(SQLインジェクションや認証不備)を引き起こすリスクが潜んでいます。

つまり、「AIが作ってくれた80%のアウトプット」に対して、「残り20%の検証・修正・セキュリティ担保・設計の整合性確保」を行える人間の存在が、これまで以上に重要になっているのです。

3. エンジニアとPM/PMOに求められる役割の劇的な変化

AIの登場によって、IT現場で働くプレイヤーの「価値の源泉」は大きく変化しました。

① エンジニア:「コードを書く人」から「コードを審査・設計する人」へ

これまでの優秀なエンジニアの条件は「構文を暗記していて、バグのないコードを速く書けること」でした。

しかし現在、単純なコーディング速度では人間はAIに立ち打ちできません。 これからのエンジニアに求められるのは、「AIが生成したコードの妥当性を瞬時に見抜き、リファクタリングし、全体アーキテクチャに安全に組み込む『コードレビュアー(審査官)』としての能力」です。

言語の文法やフレームワークの仕様、設計パターン(デザインパターン)やセキュリティの基礎知識がない状態(コピペエンジニア)でAIを使うと、バグや脆弱性の原因を自力で追及できず、最終的にプロジェクトを炎上させることになります。

② PM / PMO:「進捗を追う人」から「AIをチームに組み込むプロセスマネージャー」へ

プロジェクト管理者(PM/PMO)の役割も劇的に変わります。

従来のPMO業務の多く(進捗表の更新、会議の議事録作成、課題管理表の整理、各種報告書の作成)は、AIと自動化ツールを組み合わせることで、作業時間を半分以下に削減できます。

浮いた時間を使ってPM/PMOが果たすべき真の価値は、以下の2点です。

  1. チーム全体の「AI活用プロセス」を標準化すること(セキュリティガイドラインの策定、AIプロンプトの共有化)
  2. 人間でしかできない「泥臭いステークホルダー調整」と「定性的なリスク予測」に集中すること

4. 現場で今すぐ使える!開発・PMでのAI活用シーン3選

現場で効果を発揮している、具体的かつ安全なAI活用シーンを3つご紹介します。

シーン1:レガシーコードの解読とドキュメント化

「過去の担当者が残した、コメントもない複雑なJavaコードやSQL」を読まされるのはエンジニアのストレスですが、AIはこれが大得意です。 コードを貼り付け、「この処理のロジックをステップバイステップで日本語解説し、入出力の仕様を表形式でまとめて」と指示するだけで、解読時間が10分の1になります。

シーン2:単体テスト(Unit Test)ケースの自動生成

自分で書いたコードに対して、「この関数に対するJUnit(またはPyTest)のテストコードを作成して。特に境界値(null、空文字、上限値オーバー)のテストケースを漏れなく含めて」と依頼します。人間が見落としがちなエッジケースを網羅したテストコードが一瞬で完成します。

シーン3:PMOにおける「テキストからのタスク・リスク抽出」

会議の文字起こしテキストや、チャットツールでの雑多なやり取りをAIに読み込ませ、「この会話から、1. 決定した仕様、2. 未決事項と担当者、3. 懸念されるスケジュールリスクの3点に整理して抽出して」と指示します。議事録作成が数分で完了し、タスクの漏れを防ぐことができます。

5. 現場で導入する際のセキュリティとガイドライン

開発現場でAIを導入する際、最も注意すべきは「ソースコードや顧客データの流出」です。

企業としてAIを導入・利用する際は、必ず以下のルールを明確にしておきましょう。

  • パブリックな無料AIエディタに機密ソースコードをそのまま貼らない
  • オプトアウト設定(学習に使わせない設定)が担保された法人契約ツール(GitHub Copilot Enterprise、ChatGPT Team/Enterprise、Azure OpenAI等)を使用する
  • 顧客個人情報、認証キー、パスワード、接続文字列などは伏字(ダミー化)にしてから投げる

技術の利便性とセキュリティリスク管理の両立(ガバナンス)ができて初めて、プロの開発現場と言えます。

6. まとめ:AIは開発チームの強力な「加速装置」

システム開発におけるAI活用は、「人間の仕事を奪う脅威」ではありません。 面倒な定型コードの記述やドキュメント整理をAIに任せ、人間は「本当に行うべきアーキテクチャ設計」「顧客の課題解決」「複雑なビジネスロジックの整理」に集中するための強力なアクセラレーター(加速装置)です。

AIという優秀な相棒を味方につけ、開発スピードと品質を両立させるチームへ。

次回(第2回)からは、具体的な開発フェーズ(設計・要件定義・レビュー)において、どのようにAIを組み込んで実践していくのか、具体的なプロンプトや運用手順を交えて深掘りしていきます!ご期待ください。