「大企業部長向けプレゼン資料」という型の効き方 — Claude Code に計画から完了報告まで
ブログの source リポジトリが、写真を原寸のままコミットする運用をしていたので 1.9GB まで膨らんでいました。スモールスタートで始めた当時の設計で、当初はそれで十分だったと思っています。対策を決めるにあたって今回は、Claude Code に「大企業でプレゼンするようなイメージで」と頼み、戦略提案から完了報告までを資料として作らせ、それを見て判断する進め方を試してみました。調査・資料作成・実装は Claude Code、私は資料を読んで判断する役です。
この記事の主役は出来上がった資料6本で、本文は案内役に徹します。結果として、リポジトリは 1.9GB から 288MB になり、その日のうちに実装まで終わりました。
背景と、試してみた理由
リポジトリには記事の素材としてスマホの写真を原寸のまま置いていて、月に300MBほどのペースで .git が育っていました。対策の選択肢は、別のセッションが issue に一次検討として6案並べてくれていましたが、どれか1つで決まる話ではなく、履歴書き換えのような不可逆な作業も含みます。
これまでは、調査、検討、提案を Claude Code とチャット形式で何往復もしながら、一緒に少しずつ進めるような形でした。今回は、私の判断にかける時間を短くし、かつ AI の検討をより正しく行えるように、計画のまとめ資料を作らせてみたらどうなるかを試すことにしました。
最初のプロンプト
担当セッションにこう頼みました。原文のままです。
> 検討して、最有力案を1つ作って、私にプレゼン資料を使って提案をおねがいします。
あとでブログ化して載せるので、html形式とかhtmlで再生できるスライド形式のようなもので
おねがいします。
大企業でプレゼンするようなイメージでおねがいします。
メリットデメリットの整理や、現状の課題、短期的視点だけでなく中長期的な視点なども
忘れないようにおねがいします。
有力案は1つですが、対抗案も用意をおねがいします。
本件を解決することが重要ですが、もっと重要なのは全体としての個人開発を
適正に進められるようにするということです。
また、issueに書いてある選択肢はあなたが別のセッションで簡単に一次検討したものに
なるので、他の案や、そもそもその選択肢が検討外れはケースもあるかもしれません。
できあがった資料をみて、どうするか判断したいと思います。指定したのは、想定読者 (大企業向けのプレゼン)、入れてほしい観点 (現状・メリットとデメリット・短期と中長期・対抗案・全体最適)、そして既存の選択肢を疑ってよいことです。「大企業」と書いたのは見た目のためではなく、厳密に、抜け漏れなく、リスクまで検討してほしいという水準の指定です。
戦略提案 (全21枚)
依頼から20分ほどで出てきたのがこの資料です。中身は資料をご覧ください。なお、この記事で使った Claude Code のモデルは Fable 5、effort は xhigh です (このセッションの作業はすべてこの設定で行っています)。
資料をレビューする — 審議録
資料を読んで、いくつか気になる点を指摘しました。Claude Code とのチャットの往復を3回ほど繰り返し、原本の保管先の設計が一部変わっています。資料に間違いや修正が必要な箇所もありましたが、ブログ化する予定もあったので、資料は直さず議事録に残す形で進めると決めました。このやりとりは、あとから「大企業で発表したあとの質疑応答記録のように」と頼んで審議録に整形してもらったものです。
実行計画書
方針が決まったところで、同じ型で実行計画書を頼みました。
> 承認をもらえたので実行計画を立てるということです。
実行計画(設計書)の資料をつくってもらいたいです。
同じく大企業で部長クラスに報告する内容と考えてください。
それをみて、実行前に最終判断します。判断というか、リスクが漏れてないか、
具体的な対応方法や計画に問題がないかを確認します。こちらも依頼から20分ほどで出てきました。戦略提案をレビューした段階で方針に問題はないと思っていたので、実行計画は念のため作ってもらった形です。内容を確認して、そのまま承認しています。
実施 — 実施録
実施も Claude Code に任せました。フェーズごとに判断ポイントがいくつかあり、Claude Code から指定された場面で私が判断と簡単な操作をしています。実施録は、実施と完了報告が終わってから資料としてまとめたものです。
完了報告
| 項目 | 移行前 | 移行後 |
|---|---|---|
.git のサイズ | 1.9 GB | 288 MB |
| 増加ペース | 約 300 MB/月 | 20〜40 MB/月 (見込み) |
| 写真の原本 | リポジトリに単一保管 | USB の原本庫へ |
第三者レビュー
ここまでの資料は、実施した Claude Code 自身が書いたもので、どうしても「うまくいった」側に寄ります。そこで公開前に、この作業の文脈を持たない別の Claude Code エージェントに資料を渡し、懐疑的な監査役として批判させました。15点の指摘のうち重要度の高いものは、計画にあった予行演習を省略していたこと、「多重保全」と書いた原本とバックアップが同じ USB 1台にあったこと (指摘を受けてバックアップを別の媒体にも複製)、増加ペース「20MB/月」の根拠が弱いこと (20〜40MB/月の帯に訂正) などです。割り引いて読む材料として、そのまま載せます。
やってみて思ったこと
私はもともと大企業で働いていたので、資料を開いた時の感想は「まあまあこんな感じ、だいぶしっかりしているなあ」でした。私自身で作ると、リスク管理のような後半の節は時間切れで書けないことがこれまで多かったです。人間はメインの部分に時間を割いて、それ以外の手が薄くなることもあるかと思います。AI はどのフェーズ・どの部分も同じ熱量で作れます。出来栄えとしては素晴らしいと思いました。
一方で分量です。21枚と聞いた時点で「多い」と感じ、読むのに時間がかかりました。もう少し濃度を上げて、私のレビューと確認の時間を短くできればよかった。大企業の社長は時間が限られているので、「社長向け」と頼んでいれば詳細を省いて簡潔になったかもしれません。
「大企業向け」と指定したのは、内容を充実させるためでした。個人開発という前提で頼むと検討が甘くなる印象があったので、あえてそうしています。中小企業向け、スタートアップ向け、個人開発向けと指定を変えたらどうなるかは、別の課題で試してみたいところです。
資料があって私の頭の中が整理しやすかった部分もありますが、レビューに時間がかかったので、判断が楽になったとは思っていません。それよりも、資料にまとめる過程で Claude Code 自身がこの課題を正確に理解できたことの方が大きいと思っています。資料は私のためのものであると同時に、AI が自分の理解を組み立てた出力でもある。この記事で伝えたいのは、その意味で「AI が上手く動いてくれた」ことです。
AI とチャットで相談しながら進めると、決定事項をひとつずつ決めていって、だんだん細かい部分に入っていく傾向があると思います。そうすると、途中で前提が変わったり、別のよい案が出てきたりしたときに、最初に立ち戻ってやり直したり、総合的に考え直したりするのが苦手だと感じています。先に資料を作らせて AI が全体像を見渡し、計画を立ててから進めることで、俯瞰の目線を失わずに先へ進めるのではないか、と思っています。
資料を作らせるメリット・デメリット
メリット:
- 先に全体像を見渡してから進められるので、途中で前提が変わっても俯瞰の目線を失いにくい
- 資料にまとめる過程で、AI 自身の課題の理解が深まる
- リスク管理のような後半の節まで同じ熱量で書かれるので、抜け漏れに気づきやすい
デメリット:
- 資料を読むのに時間がかかる。今回は21枚で、私のレビュー時間が伸びました
- 資料1本あたり20分ほどの作成時間がかかる。チャットで返事をもらうより待ちます
プロンプト例と、前提条件
今回使ったプロンプトは上の2本で、指定したのは想定読者と観点です。型にするとこうなります。
<課題の issue や背景> を検討して、最有力案を1つと対抗案を用意し、
<想定読者: 大企業の部長 / 社長> に報告する水準のスライド (HTML) で提案してください。
- 現状の課題と実測データ・選択肢のメリット/デメリット・短期と中長期の視点・
リスクと対策・判断してほしい事項 を含める
- 既存の選択肢は一次検討なので、別の案や前提の誤りがあれば指摘してよい
- 数値は 実測 / 推定 / 要確認 を区別して表記する承認したあとは「同じ型で実行計画書を」「完了報告と議事録を」と続けています。
ただし前提があります。私の場合、課題は GitHub の issue で管理していて、実測に必要なリポジトリも、過去の経緯も、検証できる環境も、すべて Claude Code の手が届くところにありました。資料の数字は Claude Code がその場で測り直したものです。何もデータがないところから同じプロンプトを投げても、ここまでの精度にはならないと思います。
「大企業の部長向け」の一言が効くのは、読者が決まるからだと思っています。読者が決まれば、その読者が必ず聞くこと (費用は、リスクは、やめる条件は、他の案は) が決まり、それに答えるために調査の順番と深さが決まる。「大企業」は見た目の指定ではなく、答えるべき問いの水準を渡していたのだと思います。
おわりに
一人で開発していると、判断の過程は頭の中で済ませてしまいがちです。今回 Claude Code に資料を作らせてみて分かったのは、整理することで理解が深まるのは私よりも Claude Code の側だった、ということでした。プロンプトに想定読者を一言足す、という小さな試みで確かめられます。