【AI航海日誌】AIプロジェクトマネージメント～ドキュメント管理の目的～

こんにちは、ひでピチュです。

前回は、AIと一緒に取り組んだアイデア創出ワークショップについて書きました。顧客分析をして、アイデアを出して、戦略を考えて。そうやってプロジェクトを進めていくと、当然ながら、その過程では大量のドキュメントが生まれていきます。

プロジェクト計画書や開発基本計画書などは、かなり早い段階から作っていました。記事にするにあたって、後になって見えてきた課題や気づきをテーマごとに振り返って書いています。今回取り上げるのは、その中でも何度か試行錯誤することになった「AI時代のドキュメント管理」の話です。

結果から先に書くと、私は増え続けるドキュメントを管理するために、ファイル同士の関係まで図で表示できるナレッジ管理ツールを自作しました。自分で言うのも何ですが、なかなか良くできたと思います。

ところが、完成してしばらく使っているうちに、「これ、もしかすると、もう要らないのではないか」と思い始めました。

今回は、そこに至るまでの話です。

AIに計画書を作らせてみた

会社員時代、私はプロジェクトマネージャーとして、それこそ何十冊という資料を作ってきました。新しいプロジェクトが始まれば、体制や役割分担、会議体、リスク管理などを定めたプロジェクト計画書を作り、目的や市場ニーズ、課題、KGI・KPI、ロードマップなどを整理した開発基本計画書を作ります。

その後も、事業を拡大していくための戦略書や、システムを作るための要件定義書、画面仕様書などが次々と必要になります。そして、それらは随時更新され、資料間の整合性がズレることもしばしばです。

以前であれば、これだけでもかなりの仕事でした。関係者と社内外で打ち合わせを行い、構成を考え、PowerPointやWordで書き、何段階ものレビューを受けて、また修正する。上流の資料であれば、一つ作るのに数日から数週間かかることも珍しくありませんでした。

ところが、これをAIに手伝わせてみると恐ろしく速い。こちらが目的や前提条件を伝え、何度かやり取りをしていくだけで、それらしい計画書がどんどん形になっていきます。

もちろん、そのまま使えるわけではありません。AIはもっともらしい内容を勝手に付け加えることもありますし、こちらの意図を取り違えることもあります。それでも、ゼロから人間が書くのに比べれば圧倒的に速く、最初のうちは「これは便利だ」と素直に感心していました。

問題は、その後でした。

AIが速くなると、ドキュメントが増える

AIを使うと、ドキュメントを作るコストが一気に下がります。計画書を作り、検討結果を反映して改訂し、新しい戦略書を作り、仕様書を作り、さらに仕様変更が発生すると別の仕様書にも反映する。AIとの会話の途中で新しいルールが決まれば、それもどこかに残しておかなければなりません。

つまり、AIで文章を作るのが速くなると、今度はドキュメントそのものがものすごい勢いで増えていきます。

最初は、自分や関係者が読むことを前提に、これまで会社でやってきたのと同じようにWord形式で管理していました。ところが、すぐに更新が追いつかなくなりました。AIとの会話で決まった内容をWordにコピーし、別の文書にも同じ内容を反映し、古い記述が残っていないか確認している間に、また次の検討で仕様が変わる。AIのおかげで考える速度は上がっているのに、人間が文書をメンテナンスする部分だけが昔の速度のままなのです。

これは思っていた以上に厄介でした。AIによって効率化したはずなのに、別のところに新しいボトルネックができてしまったわけです。

AIに覚えさせればいいと思った

それなら、作ったドキュメントをAI自身に持たせてしまえばいい。そう考えて、GemsなどのカスタムAIに、計画書や仕様書をナレッジとして登録してみました。これなら毎回同じことを説明しなくても済むだろうと思ったのです。

ところが、これも実際に運用してみると問題がありました。

一番困ったのは、情報の鮮度です。固定ファイルとして登録した瞬間、そのファイルは古くなり始めます。今日の打ち合わせで方針を変えても、昨日登録したナレッジには反映されていません。新しい資料と古い資料が混在すると、AIがどちらを正しい情報として扱っているのか分からなくなることもあります。

さらに、AIにはAI特有の困った挙動があります。こちらが細かく指示したつもりでも勝手に省略したり、ファイル名を変えたり、指示の一部を「このくらいでいいだろう」と解釈してしまうことがあります。もっと困るのは、性能の劣るAIでは、参照できていない資料を、あたかも読んだかのように説明することがある点です。

そうなると、便利になったはずなのに、「本当にその資料を読んだのか」「その情報はどこから持ってきたのか」という確認作業が必要になります。人間の新人なら一度注意すれば覚えてくれるかもしれませんが、AIの場合はセッションが変われば、また同じ注意を繰り返さなければならないこともあります。

そもそも、人間向けに清書する必要があるのか

そんなことを繰り返しているうちに、考え方そのものが少しずつ変わってきました。

それまでは、ドキュメントというものは人間が読むものだと思っていました。だから見出しを整え、レイアウトを調整し、場合によっては表紙をつけて、読みやすい形に清書する。会社員時代にはそれが当たり前でした。

しかし、このプロジェクトで一番頻繁にドキュメントを読むのは自分とAIだけです。しかも自分ですら、すべてに目を通すことがボトルネックになってきました。

そこで、人間がすべての資料を精読することを前提にするのは諦めて、初めからMarkdown形式を中心にすることにしました。

MarkdownならAIがそのまま読み書きできます。余計な装飾が少なく、Gitで変更履歴や差分を管理しやすく、ファイル同士の参照もさせやすい。見栄えのいいWord文書が必要になったときだけ、最後に人間向けの形式に変換すればいいわけです。

この頃から、私の中でドキュメントの主たる読者が、人間からAIへ変わりました。

今度はMarkdownが増えすぎた

ところが、WordをMarkdownに変えればすべて解決するかというと、当然そんなに簡単ではありませんでした。

今度はMarkdownファイルが増えていきます。プロジェクト全体のルール、事業戦略、システムの基本設計、機能ごとの仕様、画面仕様、作業中の計画、タスクリスト、決定事項、AIへの指示、過去の検討記録。気がつくと、どれが何のためのファイルなのかを人間の側が把握するのも大変になってきました。

しかも、AIは一つの会話の中ですべてを永久に覚えているわけではありません。チャットを分ければ、前のチャットの文脈を十分に共有できないこともありますし、コーディングをするAI、文章を書くAI、調査をするAIと複数のAIを使い分けるようになると、「どのAIに、どの情報を、どこまで渡すか」という別の問題も出てきます。

全部渡せばいいわけでもありません。大量の情報を一度に渡すと、重要な指示がその中に埋もれたり、コンテキストの上限に近づいたりします。そこで、プロジェクト全体で共有する情報、特定の機能だけで必要な情報、特定のAIだけが必要とする指示、一時的な作業計画、確定済みの仕様という具合に、知識を分けて管理するのが賢明です。

考えてみると、この頃の私は、AIに仕事をさせるために、AIが迷わない情報構造を設計する仕事をしていたことになります。

ナレッジ管理ツールを作った

ファイルが増えてくると、今度は私自身がプロジェクト全体を把握することが難しくなってきました。「この仕様書は何を参照しているのか」「このルールを変更すると、どこに影響するのか」「どれが固定されたルールで、どれが作業中の計画なのか」といったことを、いちいちファイルを開いて確認しなければなりません。

そこで、これらを何とか一目で分かるようにしようと考え、Vis.jsというライブラリを使って、ブラウザ上で動くナレッジ管理ツールを作りました。

Markdownファイルをノードとして表示し、関連するファイル同士を線でつなぎます。変更の少ない静的なルールと、頻繁に更新される計画などは色や形で区別し、ロードマップや現在の状況を一覧できるコックピットも用意しました。AIに渡す指示を生成する仕組みや、過去の文書と現在の文書を比較してルールの差分を抽出するためのプロンプトまで組み込んでいきました。

ツール作りは、エージェント型AIの真骨頂です。これ自体は、話し始めるときりがないので、また日を改めて書こうと思います。

作り始めた頃は、単にファイルの関係が見えればいいくらいに思っていたのですが、やっているうちにだんだん大掛かりになっていきました。それでも、完成した画面を見たときは「おお、これはなかなかいいものを作った」と思いました。プロジェクトの知識がネットワーク図としてつながり、人間が見ても全体像を把握しやすい。これなら管理できると思ったのです。

しかし、この管理すらAIが担うようになっていくでしょう。いや、既にそうなっていると言えるかもしれません。

AI自身が必要な情報を探すようになった

その変化を象徴する一つが、AGENTS.mdのような仕組みです。

簡単に言えば、「このプロジェクトで仕事をするときは、まずこれを読んでください」というAI向けの案内板のようなものです。プロジェクトの概要や守るべきルール、テスト方法、参照すべき資料などを書いておけば、対応しているAIエージェントが作業を始める際の入口になります。

ここで面白いのは、AGENTS.mdそのものにすべての情報を書く必要はないという点です。むしろ、「詳しい仕様はこのファイルを見る」「この機能についてはこのフォルダを参照する」といった案内を置き、必要な情報はAI自身に探しに行かせる使い方ができます。

さらに、Agent Skillsのような仕組みも広がってきました。例えば「PDFを処理する」「コードレビューをする」「記事を書く」といった業務ごとに、手順や注意事項、参考資料、必要であれば実行するスクリプトまで一つのまとまりとして用意しておきます。対応しているAIエージェントは、それらを最初から全部読み込むのではなく、まずどんなSkillがあるかを把握し、必要になったときにだけ該当する内容を読み込みます。

つまり、これまで人間が「この仕事にはこの資料が必要だろう」と考えてAIに渡していたものを、少しずつAI自身が選び、必要なときに読み込むようになってきたわけです。

こうした「必要なコンテキストを必要なときに読み込む」という考え方は、AIエージェントの世界で主流になりつつあります。象徴的なのが、これまでカスタムAIとして使われてきたChatGPTのGPTsや、GeminiのGemsです。どちらも、自分専用の指示や知識をあらかじめ持たせる仕組みでしたが、従来の形からSkillsなどの新しい仕組みへ移行する方向が示されています。

これは単なる名称変更ではなく、考え方そのものが変わってきたということだと思います。一つの専用AIに大量の知識と指示を持たせるのではなく、共通のAIが仕事に応じて必要な知識や機能をその都度選んで使う。私自身、GemsのようなカスタムAIに大量の資料を持たせようとして苦労していたので、この変化には少し拍子抜けしました。

自分が苦労して解決しようとしていた問題を、AI側の仕組みそのものが別の方法で解決し始めていたからです。

これを実際に使い始めてから、自分で作ったナレッジマップを眺めていて、ふと疑問が湧きました。

人間がすべてのファイルの関係を把握し、読む順番を決め、必要な資料をAIに渡し、そのためのポータルまで作る。そこまで人間が面倒を見る必要はないのではないか。作ったナレッジ管理ツールも、使う機会はあまりありませんでした。

ドキュメントが不要になったわけではない

もちろん、AIが進化したからといって、ドキュメントそのものが不要になったわけではありません。むしろ、AIが自律的に仕事をするようになるほど、正しい仕様書やルール、設計思想、過去の決定事項は必要になります。

変わり始めているのは、ドキュメントそのものではなく、その管理の仕方なのだと思います。

これまでは、人間が読む順番を考え、人間が資料を探し、人間が必要な情報をAIに渡していました。それがこれからは、AIが必要な情報を自分で探せるように、知識の置き場所や入口を人間が設計する方向に変わっていく。

会社員時代のPMの仕事は、きれいな資料を作り、それを関係者に説明し、共通認識をそろえることが大きな割合を占めていました。AIエージェントを相手にすると、その仕事の中身が少し変わります。立派な資料を作ることよりも、AIが迷わず、古い情報や間違った情報を拾わず、必要な情報にきちんとたどり着ける環境を作ることの方が重要になってきます。

そう考えると、AI時代のドキュメント管理とは、文書を書く技術というよりも、「コンテキストをどう設計するか」という話に近いのかもしれません。

AIに任せても、承認は必要

AIが進化すると、AIに任せることが増え、人間がすべてを把握することはますます難しくなります。だからといって、中身をよく確認しないまま承認していけば、後でとんでもないしっぺ返しを受けるのは、人間同士の仕事と一緒です。

そこで重要になるのが、どのポイントを人間がチェックし、どこに承認ゲートを設けるかです。

ところが、この承認ゲート自体をAIに設計させると、今度は安全を見込んで、やたらとゲートを増やしてしまうことがあります。何でも人間に確認させていたのでは、せっかくAIを使っている意味がありません。

逆に、任せすぎれば事故が起こる。

どこまでAIに任せ、どこから人間が確認するのか。その塩梅は、使うAIや業務の種類によっても違います。このあたりは、私自身もまだ試行錯誤している最中です。

こうした試行錯誤を重ねながら、プロジェクトはいよいよ具体的な形になっていきました。次回は、実際にAIとWebサイトを作っていった話を書こうと思います。

#生成AI #AI #ChatGPT #Claude #Gemini #早期退職 #黒字リストラ #セカンドキャリア #個人開発 #事業創出 #働き方 #航海日誌 #プロジェクトマネージメント #PM #文書管理 #ドキュメント管理 #計画書 #企画書 #戦略書