コンサルティングの世界で、PowerPointスライドは成果物です。そのスライドを、AIが自動生成しました。Playwrightでヘッドレスブラウザを動かし、各画面をスクリーンショットして、Claudeがスクリプトで構成を形作り、日英バイリンガルのスライドに組み上げる。仕上がりを見たとき、少し驚きました。実用レベルでした。
この記事では、資料作成という仕事の意味が変わる瞬間と、スライドを作る力より何を伝えるかを決める力が際立つ時代の到来を書きます。若手に資料作成力を磨きたいと言われるたびに感じてきた引っかかりが、言葉になりました。
ドキュメント作成という仕事が変わりつつある
コンサルティングの世界で、PowerPointスライドは成果物です。
分析があって、示唆があって、それをスライドに落として初めて仕事をしたと認められる文化があります。良し悪しは別として、それが現実です。
SIer時代も同じでした。提案書、設計書、報告書。エンジニアが実装した機能を、非エンジニアに説明するためのドキュメント作成に、膨大な時間が使われます。私はSIer・事業会社・コンサルのそれぞれの立場で、説明する側と説明される側の両方を経験してきました。
AIはPowerPointだけでなく、WordもExcelも生成できます。プロンプトの設計やRAGで参照する情報次第で、かなり意図に近い成果物が出せる水準になってきています。エンジニア側からは、MDファイルだけで十分ではないかという意見も出始めています。ドキュメントの形式や作成そのものを問い直す動きも起き始めています。
ただ今回は、自分のツールで、自分が使う資料を、自分で動かして生成しました。それはいずれではなく、その時でした。
ツールの説明資料を、ツール自身が作る
実装したのは、ツールのスクリーンショットを自動収集してPowerPointスライドのデックに組み上げる機能です。
このツールの機能を説明するスライドを自動生成したい。各画面のスクリーンショットを含めて。
最初に、スクリーンショットに関してClaude Codeが提案したのは、html2canvasというJavaScriptライブラリを使う方法でした。ブラウザ上でHTML要素をCanvasに描画し、画像として取り出す手法です。ただ、日本語テキストが崩れるという問題が出ました。html2canvasの日本語レンダリングはGitHub上でも多数の未解決issueが積み上がっている既知の弱点のようでした（確認していません…）。
そこで私の方から、XのタイムラインでよくPlaywrightの話を見かけるがこれは使えるかと聞いてみました。使えるという回答だったので切り替えることにしました。Playwrightはヘッドレスブラウザ（画面描画なしでバックグラウンド動作するブラウザ）でページを開きスクリーンショットを撮るため、日本語フォントも含めてそのまま正確にキャプチャできます。ツールを裏側で起動し、各画面に自動でアクセスし、スクリーンショットを撮ります。その画像をPowerPointスライドに埋め込んで、日本語と英語の説明文を添えます。
スライド構成に関しては言及しませんが、仕上がりを見たとき少し驚きました。
タイトルスライド、目次、画面ごとのスライド（スクリーンショット＋箇条書き）、バイリンガル対応。指定したスライドテンプレートを用いて、統一されたデザインで出力されました。
これは実用レベルでした。
骨格もデザインも、すべて自動生成されています。初回はチューニングに若干の手が入りますが、いずれにせよ私がやったことは指示を出しただけです。
資料作成という仕事が変わる意味
この体験で、一つのことを確信しました。
資料作成スキルという概念そのものが、変容しつつある。
資料作成スキルには、3つの層があると考えています。
まず、ツールの習熟。レイアウト、フォント、色使い、（シーンによってはアニメーション）。スライドを速く・きれいに操作できること自体がスキルとして評価される時代がありました（現在もあります・・・）。
次に、論理構成力。コンサルティングファームが新人に限らずですが覚えなければならない型です。
そして、文脈を読む力。（私はいまだに苦手なのですが・・・）誰が読むか、何を決めてほしいか、どこで読まれるか。会議室のスクリーンで判断を迫る資料と、個別に読まれる資料では、同じ内容でも構成・分量・言葉の粒度がまったく変わります。この文脈を正確に読めれば、設計は自ずと決まります。
これら3層が揃って、初めて資料が作れるとされていると考えています。
今変わりつつあるのは、この3層の比重です。ツールの習熟は自動化され、論理構成の初稿はAIが叩き台を出せるようになりました。残るのは、文脈を読み、相手を動かす設計力。誰に、何を、どう届けるかを判断する力です。構造を考える、伝える順番を決める、読み手の文脈を想像する。これらはまだ人間の仕事です。しかし、それをスライドに落とすまでの作業は、急速に自動化されています。
コンサルティングファームに在籍して2年ほど。若手が資料作成力を磨きたいと言う場面に何度も遭遇してきました。そのたびに、私の中に小さな引っかかりがありました。
今、磨くべきは、本当にスライドを作る力なのか。
Playwright: 知らなかった技術が自然にやってくる
ここでも、技術は後からついてきた体験でした。
Playwrightというライブラリは名前を知っていましたが、使ったことはありませんでした。最近はXのタイムラインだけでなく、社内のAI・テスト関連の文脈でもよく名前を聞くようになっていました。
各画面を自動でキャプチャしてスライドに入れたいという目的がありました。その目的を言葉にして、使えそうなツールの候補を自分から出してみました。目的をAIに伝えると、その実現可能性や使い方まで返してくれます。この繰り返しが、AI時代の技術習得の形です（最近は、AIで情報を整理した後に、自分用のPDF本を作るのにも使っています。Packtの本が勉強になりました）。
ただし、すべてが一発で動いたわけではありませんでした。
ポモドーロウィジェットが他の画面のキャプチャに映り込む問題。タイマーの画面は描画に時間がかかるため、待機時間を延ばす必要があった問題。目次が11項目になってスライドからはみ出した問題。
これらのデバッグは、エラーや見た目の不具合を言語化して渡すプロセスでした。AIの出力を確認して、こうなっている・こうしたいとフィードバックする往復が、開発作業の実態です。
Playwrightはこうした文脈でAIエージェントとの相性が非常に良いツールです。Playwrightはコードで制御できるため、AIエージェントが指示通りにブラウザを操作し、画面を開き、スクリーンショットを撮り、次の処理に渡すという一連の流れを自律的に組み立てられます。人間が手作業で操作する部分をAIが代替できる範囲を大幅に広げるツールです。
作れると届けられるの間にあるもの
第3回で配布用アプリの話を書きました。作っても届かない道具は存在しないのと同じ、と。
今回の資料自動生成も、同じ問いから来ています。
ツールをチームに共有するとき、これを使ってみてくださいだけでは動きません。何ができるかを一目でわかる形で示す必要があります。その資料を毎回手動で作っていたら、共有のコストが高すぎます。
資料が自動生成されるなら、ツールを更新するたびに最新の資料が手元に揃います。実態と乖離した古い資料しか存在しない現場を多く見てきた身としては、これは単なる便利さではなく、ドキュメント管理の構造的な問題を解決する話だと感じました。
道具の改善と、道具の説明が、同じサイクルで回る。
これはプロダクト開発の小さな革命だと思っています。開発・テスト・ドキュメント生成を自動化されたパイプラインとして回す発想は、CI/CDやDevOpsの文脈で語られてきたものですが、生成AIによってコードを書かないユーザーでも手が届くレベルになりました。
この開発が示すこと
ドキュメントの自動生成は、プロダクト開発において長年の課題でした。コードは更新されます。でもドキュメントは古くなります。その乖離が、引き継ぎや共有のコストを押し上げてきました。
今回の実装はその一形態ですが、根本的な問いを示しています。
ドキュメントを書くから生成するに変えられるなら、何に時間を使うべきか。
伝えるべき内容を決める力、構造を設計する力、読み手の文脈を読む力。これらは自動化されません。むしろ、自動化が進むほど、この力の価値が際立ちます。
スライドを作る力よりも、何を伝えるかを決める力。その優先順位に気づいて動いているかどうかが、じわじわと差になっているのではないでしょうか。
次回は、開発フォルダが97%軽くなった日のこととセキュリティ脆弱性の発見について書きます。AIが生成したコードに、どんなリスクが潜んでいたか。そしてそれを発見・修正するプロセスが教えてくれたことについて書く予定です。
→ 第5回（近日公開）
この記事はシリーズの第4回です。続きを見逃さないようフォローしていただけると嬉しいです。
Accenture Japan - ICE (有志) により固定
インフラストラクチャ・エンジニアリングサービス | アクセンチュア
クラウドアーキテクト / エンジニア / コンサルタント – テクノロジー コンサルティング本部（ICE）
クラウド領域の仕事と募集要項 | アクセンチュア
採用情報 | アクセンチュア
アクセンチュア株式会社に所属する社員有志による運営です。アクセンチュアの社員による様々な発信をまとめています。なお、投稿内容は社員個人の見解であり、所属する組織を代表するものではありません。
Discussion