はじめに — この記事でお話しすること
こんにちは。Insight Edgeで営業を担当している塩見和真と申します。
この記事は、非エンジニアの私が、この半年間Claude Codeを実際の案件運営に使ってきた実践記です。プロジェクトフォルダの設計から、会議文字起こしの自動ナレッジ化、提案資料や報告資料の生成、チームへの展開まで。うまくいったことも、数週間で形骸化してしまった失敗も、時系列でそのまま書きます。
なお、この記事自体も、半年の取り組みを音声入力で思い出しながら話し、その文字起こしを生成AIに整形させて作ったものです（実際に口頭で話した時間は、合計15〜20分ほどだと思います）。図版も生成AIで作っています。本文で紹介する「音声で全部吐き出して、AIに形にさせる」というやり方そのもので出来ています。
結論から言えば、難しいことは何もしていません。フォルダ構成に気をつけて、ターミナルに慣れて、テキストでAIとやり取りする。それだけです。非エンジニアの方が「自分にもできそう」と思える道しるべになれば嬉しいです。
要約: 1つの案件を対象に、AIが常にプロジェクトの状況を把握している状態をフォルダ設計と、AIへの指示書（CLAUDE.md）で作り、会議の文字起こしを毎晩自動でナレッジに変える仕組みを整えました。その上で、資料作成をAIに任せるまでの試行錯誤（PowerPoint→画像→HTML）を経て、チームの週次報告も「作る」から「生成する」形に変えていきました。本文では、この半年でうまくいかなかったこと5つと、今日からできる最初の一歩までを紹介します。
- はじめに — この記事でお話しすること
- 第1章 すべての始まり — 1案件での「AIファースト」実験
- 第2章 AIが読めるフォルダを、AI自身に設計させる
- 第3章 会議情報を毎晩、自動でナレッジに変える
- 第4章 資料作成 — PowerPoint→画像→HTMLへの試行錯誤
- 第5章 プロジェクトを横に広げ、チームの報告を「コード化」する
- 第6章 チーム展開とトークン運用の勘所
- 第7章 自分自身も自動化する — 作業ログ・勤怠・自己改善
- おわりに — 非エンジニアこそ、いま始めるべき理由
第1章 すべての始まり — 1案件での「AIファースト」実験
ChatGPTやGeminiとは「別物だ」と感じた一点
弊社ではChatGPTやGeminiをかなり早い段階から業務に取り入れており、「生成AIで業務を良くする」こと自体は当たり前になっていました。そんな中でClaude Codeがネットで大きな話題になりました。
私がClaude Codeに可能性を感じたのは、自分の端末上のファイルを直接操作でき、プロジェクトのフォルダ構成さえ整理しておけば、こちらが都度情報を入力しなくても、AIがプロジェクトの状況を丸ごと理解した上でサポートしてくれるという点です。
Claude Codeというと、開発者向けのツールという印象が強いかもしれません。ただ個人的には、むしろプロジェクトマネジメントやセールス活動といった非エンジニアの業務領域でこそ活用可能性が高そうだ、という直感がありました。そこで2026年1月頃、アカウントを借りて使い始めました。
正直、最初はフォルダやファイルを自動で作らせて「へえ、こういうことができるんだ」と遊んでいた程度で、ChatGPTやGeminiとの違いもわかりにくかったです。ただ「これはチャットAIとは別物だろう」という感触はあったので、ちゃんとプロジェクトで試そうと決めました。ちょうど年度末に稼働の空きがあったため、前年度から小さく始まっていた案件を題材に、プロジェクト運営を丸ごと「AIファースト」に切り替える実験を開始しました。
AIファーストの思想 — 「AIがプロジェクト情報を漏れなく理解している」を前提にする
実験にあたって置いた大枠の思想はひとつです。AIが、今のプロジェクト情報を漏れなくすべて理解していることを前提にする。
ChatGPTやGeminiを使うとき、私たちは「今こういう状況で」と説明したり、必要な資料や文字起こしをその都度貼り付けたりします。しかし、チャットにその都度貼り付けるやり方では、人が渡せるインプットはせいぜい数ファイル程度です。実際のプロジェクト情報はそれとは比べものにならない量があります。顧客との最初のメール、Slackのやり取り、提案資料、そして顧客会議も社内会議も含めたすべての会議——。
これらが全部AIに入っていて、しかも常に最新に更新されていれば、都度の情報入力なしでAIが作業をサポートしてくれるはずです。それどころか、人が認識できていなかったことまで補足して助けてくれます。そういう使い方が可能になると考えました。まず作るべきは、この状態を成立させる「器」でした。
現実 — ファイルは2つのクラウドに散らばり、フォルダは汚い
ここで弊社の状況です。Insight EdgeではGoogle DriveとSharePointを併用しており、ざっくり言うとGoogle Driveはエンジニアが、SharePointは非エンジニアがよく使うという住み分けになっていました。そして実のところ、どちらのフォルダも汚い。命名規則や置き場所の統一ルールがなく、AIどころか人間でも中身を把握するのが難しい状態です。おそらく多くの会社で似た状況ではないでしょうか。
実験対象の案件も、非エンジニアのファイルはSharePointに、開発者のファイルはGoogle Driveに、と分かれて置かれていました。まずはこれを集約する必要があります。
やったことはシンプルです。
- Google DriveとSharePointの関係するフォルダだけを、自分の端末のローカルに同期する（クラウド上のままだとClaude Codeが直接処理しづらいため）
- ローカルに揃ったファイル群にClaude Codeでアクセスし、中身を全部確認してもらい、新しく作る実験用プロジェクトフォルダに整理しながら移してもらう
なお、集約したのは資料や議事録といった業務側の情報だけで、開発のコードや成果物はGitHubに置いたままです。
このとき実際に打ち込んだ指示は、こんな調子の文章でした。
この2つのフォルダに、〇〇案件のファイルが散らばっています。全部中身を確認して、新しく作った実験用フォルダに整理しながら移してください。分類に迷うものは私に聞いてください。
特別な呪文は何もありません。ポイントは、元のフォルダが汚くても関係ないということです。「大枠このあたりのフォルダにある」さえわかっていれば、きれいにするのはClaude Codeの仕事です。最初の一歩が「コードを書く」ではなく「片付けを任せる」だったからこそ、非エンジニアでも入っていけたのだと思います。
ベースにSharePointを選んだ理由
集約先はSharePointにしました。理由は4つあります。
- チームで同期できる: ローカルで修正・更新したファイルは、多少のラグはあれど、同じフォルダを同期している他メンバーの端末にも反映されます。個人フォルダではなく共有フォルダでやることに意味があります
- 誤削除が起きにくい: SharePointはフォルダを削除しようとするとアラートが出ます
- 最悪、巻き戻せる: 削除してもバックアップから復元できます
- 非エンジニアが日常的に扱える: ファイルのバージョン管理といえばgitが本筋ですが、チームの非エンジニア全員が日常的に使う前提では、同期も復元もGUIで完結するSharePointのほうが現実的でした
AIに端末上のファイル操作を任せる以上、「変な処理をしても復元できる」という安心は重要でした。少人数の実験とはいえ、この保険があったからこそ思い切って任せられました。
こうして、DriveとSharePointに散らばっていた案件ファイルが、1つのSharePointフォルダに集まりました。次は「AIがこれを理解して、プロジェクト運用を回せる形」にする番です。
非エンジニアへのポイント: 最初の仕事はコードじゃなくて片付け。汚いフォルダはAIに掃除させればいい。
第2章 AIが読めるフォルダを、AI自身に設計させる
CLAUDE.md — Claude Codeの「最初に必ず読まれる指示書」
ここで少しだけClaude Codeの仕組みを補足します。Claude Codeには CLAUDE.md という特別なMarkdownファイルがあります。作業フォルダにCLAUDE.mdを置いておくと、Claude Codeを起動したとき、その中身が毎回必ず最初にAIへの指示として読み込まれます。「このプロジェクトはこういうもので、情報はここにあり、こう振る舞ってほしい」を書いておける、いわばプロジェクトの取扱説明書です（詳しくは公式ドキュメントにも説明があります）。
つまりCLAUDE.mdの中身が、そのフォルダでのAIの働きの質を大きく左右します。では何を書けばいいのか。私はここで、CLAUDE.mdそのものも、フォルダ構成も、Claude Codeに考えてもらうことにしました。「AIファーストでプロジェクトを回したい。AIが最小の読み込みで状況を把握できるフォルダ構成はどうあるべきか」を相談し、設計案を出してもらい、実際にフォルダを作るところまで任せました。
できあがったフォルダ構成
Claude Codeと相談してできた構成がこちらです（実案件のものを一部簡略化しています）。
余談ですが、最初にAIが提案してきたのは、英語のいかにもそれらしい、格好いいフォルダ名でした。ただメンバーは全員日本人なので、日本語のフォルダ名に作り直してもらっています（結果として少し不思議な語感の名前もありますが、そのまま運用しています）。
設計の根っこにある原則は3つです。
| 原則 | 内容 |
|---|---|
| 情報の一元化 | 同じ情報を複数箇所に置かない。正本は必ず1箇所 |
| コンテキストの圧縮 | 00_案内 が「プロジェクトの頭脳」として機能し、人もAIも最小の読み込みで現状を把握できる |
| ツールの住み分け | ドキュメントはSharePoint、タスクはGitHub Projects、コードはGitHubと役割を分離 |
半年運用してわかった「本当に大事な3つ」
フォルダはいくつもありますが、半年運用してみて、本当に大事なのは CLAUDE.md・00案内・20会議 の3つだと感じています。
00_案内フォルダは「プロジェクトの頭脳」です。中には次のようなMarkdownが入っています。
- 案件全体サマリ（基本情報・スコープ・マイルストーン）
- 現在地と次に考えること（進捗と直近アクション）
- 主要論点（継続議題・検討中の論点）
- 決定事項サマリ（確定した合意の記録。追記のみ、上書き禁止）
- 過去経緯サマリー（意思決定の流れの歴史）
- フォルダ索引（どこに何があるかの「地図」）
CLAUDE.mdには「まず00_案内の各Markdownを必要に応じて読み、フォルダ索引を地図として、足りない情報は各フォルダへ取りに行くこと」という動き方を書いています。これだけで、Claude Codeを起動した瞬間に「今この案件がどういう状況か」をAIがおおよそ把握し、不足があれば自分で最新情報を取りに行く、という状態ができます。なお「追記のみ・上書き禁止」のようなルールはCLAUDE.mdに書いて守らせていますが、AIが100%守る保証はないので、大事なファイルは人もときどき目を通すのが前提です。
20_会議フォルダは「情報の源泉」です。プロジェクトの情報には、Slackやメールのような非同期のやり取りもありますが、大部分は社内・社外のミーティングで話され、合意されます。会議で話したことがほぼすべてと言ってもいい。だから全会議の文字起こしをこのフォルダに置いていくことが決定的に重要になります。会議のたびに文字起こしを置き、毎日のバッチ処理でClaude Codeが新しいファイルを読み、00_案内の各Markdownを自動で最新化する。このフォルダ1つで「常に最新のプロジェクト情報をAIが理解している」状態が完結します（バッチの中身は次章で詳しく話します）。
過去の情報も可能な限り取り込む
器ができたら、最後に過去分の取り込みです。前年度までのプロジェクトファイルをClaude Codeに読ませて、可能な限り経緯を理解してもらい、過去資料はアーカイブ側のフォルダへ整理してもらい、理解した内容で00_案内の各Markdownを更新してもらいました。当時は文字起こしを残していなかった会議もあるので完全ではありませんが、「その時点で復元できる限りのプロジェクト情報が1つのフォルダに整備された」状態がこれで完成しました。
非エンジニアへのポイント: フォルダ設計もCLAUDE.mdもAIに相談して作らせればいい。人間が決めるのは「AIファーストでやる」という方針だけ。
第3章 会議情報を毎晩、自動でナレッジに変える
「都度インプット不要」が確認できた瞬間
実験フォルダができあがったので、Claude Codeに参照させてみると、私が追加の説明をしなくても、プロジェクトに関する情報提供やサポートをしてくれることが確認できました。ChatGPTやGeminiのように毎回ファイルを貼り付けるのではなく、ちゃんとフォルダに入れておけば、その手間なしでAIが状況を踏まえて動いてくれる。「これはいける」と思ったのがこのタイミングです。
プロジェクト情報の大部分は、会議で生まれて消えていく
次は「これを運用として回すには？」です。プロジェクトの情報源を考えると、Slackやメールもありますが、大部分は会議です。社内の定例も、顧客とのミーティングも、対面の打ち合わせも。合意形成や重要な議論はほぼ会議で起きます。だから会議情報を起点にプロジェクト情報を更新することを前提に据えました。
やること自体は複雑ではありません。いまは主要な会議ツールなら文字起こしが標準機能で出せます（弊社はGoogle Meetをよく使っています）。要約や議事録に整える前の生の文字起こしデータを、会議が終わったら会議フォルダに入れる。それだけです。
まず内部ミーティングで実験しました。文字起こしを会議フォルダに置き、「この中身を踏まえて、00_案内の各Markdownを整理・更新して」とClaude Codeにお願いする。その後で改めてプロジェクトフォルダを参照させると、「先日の内部ミーティングでこういう話が出て、次のアクションはこうなっている」ことを前提にした作業サポートができました。これで回る、と確信した瞬間です。
自動化もClaude Codeに作らせる
確信できたら、次は自動化です。「毎晩23時にバッチが動いて、会議フォルダの新しい文字起こしを読み、各Markdownを更新して、結果をSlackに通知する」という仕組みを目指しました。特別な経験は要りません。実際、チームの他のメンバーは私のバッチをコピーして、自分用にClaude Codeに作り替えてもらうところから始めています（私自身はたまたま過去にWindowsのタスクスケジューラを触った経験がありましたが、なくても同じことができます）。
従来なら、これを非エンジニアが自力で作るのは考えられない重さの作業です。キャッチアップも含めれば膨大な工数がかかります。しかし今回は、その自動化処理そのものもClaude Codeが作ってくれます。実際の相談は、これだけです。
会議フォルダに入れた文字起こしを毎晩自動で読んで、00_案内のMarkdownを最新化する仕組みを作りたいです。夜に自動で動いて、結果をSlackに通知してほしい。必要なプログラムと設定を全部作ってください。
これだけで、Claude Codeが必要なPythonスクリプトからタスクスケジューラの設定、Slack通知まで一式を作り、その夜のテスト実行まで一緒にやってくれました。従来なら自力での調査とキャッチアップから始めるしかなかった作業が、その日のうちに動く形になりました。あくまで体感ですが、労力の差は比べものになりません。
暴走への備えも仕込んであります。バッチが書き込めるのは00_案内の決まったファイルだけに限定し、更新の前には自動でバックアップを取り、毎回の実行結果は必ずSlackに通知してログも残す。前回からの差分だけを処理する仕組みなので、同じ文字起こしを二重に取り込むこともありません。
もちろん一発では動きません。夜間に実行されたはずが翌朝Slack通知が来ていない、ということは普通に起きます。そのたびに「届いてないよ、エラー内容を確認して」とClaude Codeに伝えて直させる。これを何回か回して、いまも稀にイレギュラーで失敗することはありますが、毎日自動的に最新の会議情報を踏まえてプロジェクトフォルダが更新される仕組みが完成しました。
改めて全体の流れはこうです。
- 会議をしたら、生の文字起こしを会議フォルダに入れる（資料など他のファイルもここに集約）
- バッチがファイルを日付ベースで見やすくリネーム
- 毎晩23時、バッチが新規・変更ファイルを検出し、内容を読んで00_案内の各Markdownを自動更新
- 結果（完了・エラー）をSlackに通知。翌朝には「今の状況・論点・次にやること」が最新化されている
半年間いろいろやってきましたが、Claude Codeでプロジェクトを進行する上で本当に大事なことは、その大部分がここまでに書いた内容に集約されていると思っています。
文字起こしは「いま残さないと二度と手に入らない」資産
だからこそ強調したいのは、録音して、文字起こしして、社内に資産として残す運用を、どれだけ面倒くさくなく人が続けられるかが決定的に重要だということです。まだやっていない組織があれば、これは急ぎ着手すべき領域です。
残しておくべき理由を、経緯の面と、情報資産の面から書きます。第一に、「どういうやり取りがあったから今この状況になったのか」という経緯は、これまで人経由で伝わってきました。人経由の情報は要約され、角が取れ、潰されて届きます。生の文字起こしが残っていれば、AIを通じて「こういうやり取りがあったからこうなった」という本当の経緯をたどり直せます。
これは、情報を受け取る側——たとえばエンジニアの方々——にとっても大きいはずです。顧客が本当に言ったことが、営業の要約を経由せず生のまま残る。仕様変更の経緯を、担当営業を捕まえなくても自分でたどれる。「なぜこの決定になったのか」を、人の記憶ではなくファイルに問える。非エンジニアの側がこの運用を始めると、伝言ゲームの摩耗が組織全体から減っていきます。
第二に、モデルやツールは今後も変わり続けます。ClaudeなのかCodexなのか、選択肢はいくらでも出てくる。でも自社のドメイン情報——誰が何を話し、何を合意してきたか——は、その場で残さなければ二度と手に入りません。ツールがどれだけ賢くなっても、食べさせる情報がなければ意味がないのです。
実務のポイントも書いておきます。
- 誤字脱字や話者分離は気にしなくていい。「この発言はたぶん先方側の人だな」といった推測は、最近のAIなら文脈からかなりの精度で立ててくれます（もちろん外れることもあるので、AIの解釈を根拠に重要な判断をするときは原文に当たる前提で）。きれいな議事録ではなく、汚くていいから生のテキストを早く残すこと
- 先方が主催する会議は自社環境に文字起こしが残らないことが多く、ここが運用の穴になりがちです。NottaやPlaudのような、会議ツールに依存せず音声を文字起こしして一箇所に蓄積してくれるサービス・デバイスを使う手があります。なお、外部サービスに会議音声を渡すことになるので、利用の際は自社のセキュリティポリシーと顧客との契約上の制約を必ず確認してください
- 録音と文字起こしの利用は、お客様に必ず事前に説明して同意を得ておきましょう。社内会議についても「録音が前提」であることをチームで合意しておくのが安全です
タスク管理の実験と、正直な失敗談
会議情報が揃うと、「次に何をしなければいけないか」はAIがほぼわかります。次回までに必要なタスクの列挙は簡単にできる。これをMarkdownやExcelに書き出して週次で確認する運用でも十分回るのですが、少し面白くないなと思い、GitHub Projectsを試しました。カンバン形式でタスクがBacklog・進行中・完了と動き、担当者と詳細がテキストで残り、対応履歴もコメントで蓄積される。会議のたびにAIが新規タスクを追加し、既存タスクを自動更新する仕組みをClaude Codeと一緒に作り、実際に動きました。
——が、これは数週間で形骸化しました。原因はタスクの粒度です。AIが出すタスクは間違ってはいないのですが、「次の会議設定を誰がやるか」レベルの細かいものまで大量に生成され、プロジェクトリードが全量をカバーしきれない。タスク管理には本来「成果物を伴わないタスクはカンバンに載せない」といった粒度のルールが必要で、それを入れずに自動化した結果、整理はされているのに、リードする人間が情報に埋もれて管理しきれなくなったのです。
いまは、リードが自分の管理できる範囲でMarkdownベースのシンプルな進捗管理をする形に移行し、GitHub Projectsは「案件の状況をちょっと覗きに行く」補助用途で残しています。粒度のルールをうまく設ければもう少しやれる感触はあるので、ここは今後の宿題です。
自動化は「できる」と「運用が回る」の間に溝がある——これがこの失敗から得た一番の学びです。
非エンジニアへのポイント: 自動化の処理すらAIに作らせればいい。ただし「動く」と「運用が回る」は別物。回らなかったら素直に畳む。
第4章 資料作成 — PowerPoint→画像→HTMLへの試行錯誤
「アウトプットもAIが作る」までがAIファースト
会議情報でプロジェクトフォルダが日々更新され、AIのサポートを受けながら人が資料を作る——ここまでで既に品質の高いヒントやフィードバックはもらえていました。しかしAIファーストを掲げる以上、資料などのアウトプットそのものもAIが作ることを前提にしなければいけない、と個人的には思っていました。ここが、一番「やりきれるか」を問われるポイントです。
狙いはこういうループです。定例資料をAIが作る → その資料で人が話す → お客様のフィードバックが文字起こしとして残る → それを踏まえてAIが次のタスクと次に話すべきことを整理する → 次の定例資料をまたAIが作る。人の関与はフィードバックの部分だけに最小化して、このサイクルを回す。
まずMarkdownで骨子を作る（どの方式でも共通）
資料の作り方には後述の3方式がありますが、共通する進め方があります。いきなりスライドを作らせるのではなく、まずMarkdownで骨子を整理させることです。実際のお願いはこんな形です。
次回の定例の資料の骨子を作ってください。前回の定例のフィードバックと、直近の会議の文字起こしを踏まえて。全体のストーリー構成と、各スライドのタイトル・リード文・中身の箇条書きをMarkdownで。
この段階で「箇条書きベースのプレゼン」が出来上がるので、流れに問題がないかを先に確認できます。違和感があればすぐフィードバックして直させる。社内レビューの会議で上位者が「ここはこうすべき」と口頭で言えば、それも文字起こしに残るので、その文字起こしを踏まえてAIに骨子を更新させられます。骨子がOKになってから資料化すれば、中身はロジカルなものになります。資料作成の定番書籍に書かれている「構成から作る」手法を、そのままAIとの分業に置き換えた形です。
スライドの型と「1ページへの要求」を先に決めておく
骨子と合わせて、スライドのフォーマットと、1ページに求める要求もあらかじめ定めてAIに渡しておくようにしています。中身は当たり前のことばかりです。
- 各スライドはスライドタイトル・リード文・本文（コンテンツ）を基本必須とする
- テキストサイズはかなり大きくする
- 本文は視認性を最優先する。関係の近い要素は近くに寄せてグループにする、要素間のバランスを整える、など
背景にあるのは、資料を受け取る側の現実です。役職が上の方ほど資料の細部までは目を通しませんし、要素がごちゃごちゃしたスライドは、見ている人がどこを見ればいいのかわからなくなります。逆に言えば、そのスライドの「問い」がタイトルに書かれていて、その端的な「解」がリード文に簡潔に書かれていて、字が大きい。それだけで、資料は十分わかりやすくなります。この要求を最初に型として渡しておくと、AIが出すスライドの品質もぶれにくくなります。
コラム: フィードバックは音声入力で
ここで運用上いちばん効いている工夫を紹介します。AIへの長文フィードバックは、タイピングではなく音声入力で行うことです。
タイピングだと、頭の中で無駄に整理・要約してから吐き出してしまい、「自分がどこで悩んでいるか」「何がわかっていないか」という独り言レベルの情報が削ぎ落とされます。AIはこちらがどこまで把握しているかを知らないので、実はその独り言こそが重要な入力なのです。音声なら、整理する前の情報を全部吐き出せます。
だから、個人作業のフィードバックも音声入力、会議でのレビューも文字起こし経由。すべての起点を音声にして、そのままAIに入れる。「AIが漏れなくすべての情報を認識している状態を作る」というAIファーストの思想とも、いちばん整合する動き方だと思います。
3方式を全部試して、2つ捨てた
スライド資料をAIに作らせる手段は、大きく3つあります。全部実験しました。先に結果を見せます。
方式1: PowerPointを直接生成させる → 見栄えで早期に断念
骨子Markdownから「これをPowerPointに起こして」とお願いする方式です。資料はできます。できるのですが、見栄えがよろしくない。文字が小さい、図形の表現が微妙、結局人が中身を手直しする——顧客に出せる品質まで持っていけない部分が多く、これは早い段階で難しいと判断しました（中身がテキストデータのまま残るので、AIが後から読み直せる点だけは悪くありませんでした）。
方式2: スライドを画像で生成する → きれいだが、直せない・再利用できない
最近の画像生成モデルは品質が高く、画像内の文字もかなり正確に描けるようになっています。「スライド形式で」と言えば、タイトルデザインからメインコンテンツまで含めて、方式1よりきれいなスライドが1枚絵として出てきます（それでも誤字は混ざりうるので、文字の検品は必須です）。これをPowerPointに貼り付けて資料にする方式で、いまでも十分使えると思っています。
ただし問題が2つ。第一に微調整ができない。スライドタイトルの位置が1枚ごとに微妙にずれる。細部のズレが気になるコンサル的な感性だと「美しくない」となるし、ちょっとした文言修正でも作り直しになります。第二にAIの再利用性が悪い。画像は非構造化データなので、スライドの中のテキスト情報が「AIが次に参照できる形」で残りません。「前回どういう資料で何を話したか」をAIが直接読める状態にならないのは、AIファースト運用では痛い欠点でした。
方式3: HTMLでスライドを作る → きれい・直せる・AIが読める
最終的に行き着いたのがHTMLです。HTMLというと縦長のWebページのイメージが強いですが、PowerPointと同じ横長のスライドサイズで作ることも普通にできます。「スライドタイトル・リード文・メインコンテンツ・フッターという構成を維持して」と指定しておけば、各スライドの型を保った、非常にきれいな見た目のスライドを作ってくれます。
3方式を比べて、デザインの整い方はHTMLが頭ひとつ抜けていました。加えて修正がしやすい。「ここが違和感ある」と口頭でフィードバックすると、HTMLの該当箇所をAIが自分で見つけて、要求に合うように書き換えてくれます。いまはHTML上でスライド送り・全画面表示ができる設定まで含めて、Claude Codeのスキルという機能（作業手順を登録して呼び出せる再利用の仕組み）にしてチームに配布し、使い回しています。
さらに実運用でわかった利点がいくつかあります。
- PDFに変換できる。お客様が「PDFで欲しい」と言えばそのまま渡せる（変換用の小さな処理もClaude Codeに作ってもらったものを使っています）
- PowerPointへの変換でもほぼ崩れない。HTMLで作ったデザインは、PowerPoint化してもほぼそのまま出てくることがわかりました。「PPTXで欲しい」にも対応できます
- 生成画像と組み合わせられる。スライドの枠組み（タイトル・リード文・フッター）はHTMLで固めて、メインコンテンツ部分にだけ、コンサルがよく使うフレームワーク風のイメージ図などをAIに画像生成させて貼る。方式2の良さを部分的に取り込んで訴求力を上げられます
理想を言えば、PowerPoint単体で高品質なものが出来上がる世の中が一番です。ただ現時点の結論としては、HTMLベース＋必要に応じて生成画像に落ち着いています。一方で、生成AIがPowerPointを自動生成する品質もドンドン高まっていますので、ここは数年内にPowerPointに置き換わるのかなと想像しています。
AIに資料を作らせるときの注意点 — 受け手の認知負荷は増えうる
方式の選び方とは別に、AIに資料を作らせること自体の注意点も整理しておきます。
AIは、それっぽい要素をたくさん詰め込んだスライドを作りがちです。情報量が多く、一見すると見栄えも良い。ただよく見ると、その1枚に本来必要のない情報まで詰め込まれていることが少なくありません。そしてスピーカーが内容を腑に落とさないままそのスライドで話すと、説明も質疑もフワッとしたものになります。情報量は多いのに、ほとんどの要素は説明されないまま終わる。AI製の資料が陥りやすいパターンです。
一方で、これを承知のうえで割り切る運用にも利点はあります。開発など本質的な価値提供に稼働を割きたい局面では、資料の細部を磨き込むより、多少の詰め込みを許容してでも資料作成を丸ごとAIに任せたほうが、全体では得になることもあります。
つまり、作る側の作業が効率化されても、受け手側の認知負荷はむしろ増えうるということです。このメリット・デメリットを理解したうえで、「わかりやすい説明を優先して人が手を入れるか」「そこは割り切って、浮いた稼働を別の作業にかけるか」を場面ごとに判断する。AIに資料作成を任せるようになってからは、この見極めこそが人の仕事だと感じています。
正直な話 — 最初は気持ち悪かった
これで、「構成を考える」「テキストを練る」「スライドに起こす」というパワポ職人・コンサルの仕事の大部分をAIに移管できたことになります。
私も元はパワポ職人の側で、AIファーストに切り替えた当初は自分で考えて自分で資料をきれいに起こさないことが一番気持ち悪かったです。絶対に品質が下がると思っていました。でも結果的に回っている。そして、資料作成を裏でAIに任せて自分が対応できる案件の数が増えることのほうが、チームへの貢献としては大きい。お客様の「やりたい」に対してその日のうちに提案資料を整えて出せると、スピードに驚いていただけることも多い。半年かかりましたが、「ここはもうAIに全部任せていい」と思えるレベルに自分の感覚が変わりました。
おまけの武器 — 非エンジニアがプロトタイプを出す
資料と同じ文脈でもうひとつ。ある案件で「動くプロトタイプを見せたい」場面がありました。プロジェクトの全体像も過去の会議の文字起こしも全部フォルダにあるので、「最終成果物のイメージが伝わるプロトタイプを」とClaude Codeに頼むと、Next.jsの簡易的なモックアプリを作ってくれます。白状すると、Next.jsが何なのかを私はいまもうまく説明できません。指示したのは「最終成果物のイメージが伝わる、動く画面を作って」だけです。それを実際にユーザーに見ていただき、「最後はこういうものができるといいですよね」と会話し、反応を踏まえて進める。
動くものを早い段階で見せる効果は、想像以上でした。成果物のイメージが一気に揃い、その後の議論が具体的になります。信頼関係づくりにもつながりました。そして、これを作っているのは営業のメンバーです。会議の合間に裏でClaude Codeを回しておき、フィードバックだけ入れて、次の会議で見せる——非エンジニアでもこれができる時代になっています。
デリバリーだけじゃない — 案件創出（セールス）にも効く
営業にとっての本丸はここです。ヒアリングの打ち合わせが終わってから、1、2時間で大枠の提案資料が出せます。
お客様からの相談メールや、ヒアリングミーティングの文字起こしをインプットにすれば、お客様がどんな課題を抱えていて今どういう状況か、AIが全部整理できます。そして社内側に、過去の案件事例集・在籍する人材のケイパビリティ・提供できる支援メニュー・単価情報がMarkdownで整理されていれば、あとは組み合わせるだけです。
- ご要望に対して、どういう内容なら提案できそうか
- 「弊社にはこういう類似事例があります」：事例集から関連事例を引いてスライドに反映
- 「こういうスキルを持った人材がいるので対応できます」：ケイパビリティで補強
- 何人月でいくらぐらい、という概算：単価情報から算出
とはいえ、事例や人材の情報が最初からAIの読める構造で整理されている会社は、そう多くないはずです。弊社も例外ではありませんでした。そこで私は、すでにある資料を素材に、この構造化データを自作することにしました。
事例のほうは、会社紹介資料などで使われている事例スライドが素材です。スライドの情報をAIに読み取らせて、1事例＝1つのMarkdownファイルに構造的に書き起こさせました。各ファイルは「一言サマリー」「背景・課題」「アプローチ」「成果」「技術スタック」「提案時の訴求ポイント（どんな顧客・課題に効く事例か）」「公開可否の注意事項」という共通の型で持たせ、業種や技術のタグを付けた索引ファイルもセットで作ります。AIはまず索引で候補を絞り込み、選んだ事例の個別ファイルだけを読みに行く、という2段構えです。人材情報も同じ要領で、メンバー紹介のスライドをもとに1人＝1ファイルでプロフィールと専門領域・スキルを整理させ、専門領域別の索引を付けています。
ここまで用意しておくと、初回のお打ち合わせの文字起こしや、お客様からいただいた相談メール・資料をインプットに渡すだけで、関連する事例と対応できそうな人材をClaude Codeが自分で探し当て、提案資料に自動で付記してくれます。
「すぐに見積もりと提案が欲しい」というお客様は実際多くいます。そこに対して、短時間で資料を作り、内部のすり合わせも早々に済ませて提示する。これがAIファーストの動きでできるようになってきています。
さらにいいのは、その先です。提案から案件創出に至れば、最初の相談を起点に作られたプロジェクトフォルダをそのままデリバリーに引き継げます。一番最初の相談メールから、提案の経緯、その後のすべての会議まで、案件の全情報がひとつのフォルダに残り続ける。プロジェクトの起点からの振り返りが常にできる状態が作れるのです。デリバリーと案件創出の両輪で効く。セールスにとっての価値は、ここにあると思っています。
非エンジニアへのポイント: いきなりスライドを作らせない。骨子Markdown→合意→資料化。フィードバックは音声で全部吐き出す。
第5章 プロジェクトを横に広げ、チームの報告を「コード化」する
展開は「フォルダをコピーする」だけ
1つの案件でAIファースト運用が回ることを確認し、チームメンバーの一部にも試してもらいました。最初の数ヶ月で、「これでプロジェクトをぐるぐる回せる」という手応えが得られました。
新しいプロジェクトが始まったときの横展開は拍子抜けするほど簡単です。元になったプロジェクトフォルダをClaude Codeにコピー・初期化してもらうだけ。CLAUDE.mdもフォルダ構成もバッチも型として出来上がっているので、この半年で2つ、3つとプロジェクトを広げていきました。
親フォルダを作れば「経営者がClaude Codeを当てるだけ」の世界が見える
複数のプロジェクトがAIファーストで回り始めると、次の発想が生まれます。個別プロジェクトの親にあたるフォルダを作れば、複数案件の状況をまとめてAIが把握できるのではないか。
私は特定のお客様アカウントを担当するユニットで働いています。ユニットの親フォルダを1つ作り、そこに紐づく個別案件のAIファーストフォルダを参照させれば、ユニット全体でいま各プロジェクトがどうなっていて、全体の進捗が目標に対して良いのか悪いのかがわかる。つまり経営者や部門長が個別プロジェクトの詳細を知らなくても、そこにClaude Codeを当てさえすれば状況がわかる——これを次の目標にしました。
作り方の思想は個別案件と同じです。全体管理用のプロジェクトフォルダを1つ作り、ユニットの会議の文字起こしをすべてそこに残し、CLAUDE.mdと圧縮コンテキストを置く。ただしフォルダ構成そのものは、アカウント戦略や管理台帳なども含むユニット管理向けの形に作り直しています。子プロジェクトのフォルダは、常時読み込むことはしません。「どこに何があり、どう読むか」だけを親側に持たせ、必要なときにAIが取りに行く参照ルールでつないでいます（子案件を全部読み込むと、AIの読み込み量がすぐ溢れてしまうためです）。まだAIファースト化できていないプロジェクトは参照できませんが、「一旦それでいい」と割り切って始めました。
よくある週次報告の風景を、HTMLレポート1枚に置き換える
Before: 各案件のリードが事前にPowerPointへ記入し、リーダーが取りまとめて見栄えを調整する。After: 週1の定例で5〜10分、口頭で話すだけ。
ユニットリーダーはさらに上位の経営層へ報告する必要があります。よくあるやり方は、案件ごとのスライドに概要・進捗・リスク・晴れ曇り雨の評価を各リードが事前記入し、リーダーが取りまとめて上へ報告する形でしょう。この事前記入・取りまとめ・見栄え調整のPowerPoint運用が、もう無駄だなと思ったので、集約レポートを1枚のHTMLとして自動生成する仕組みに置き換えました。
突き合わせているのは、次の3つの情報源です。
- 売上目標の管理システム — ユニットの年次・月次目標
- 営業管理システム — 契約済み案件の個別情報
- 週次定例の口頭報告の文字起こし — 各案件リードが自分の案件の状況を5〜10分ずつ口頭で話すだけ。録音して文字起こしすれば、リスクも新しい案件の兆しも全部テキストで集まる
この3つを統合すると、売上目標に対する実績と差分、達成率、パイプラインの状況、前週からの変化、各案件の報告内容のテキスト——が1枚のHTMLレポートに揃います。その上でAIに第三者視点で見させると、ユニット全体として今が晴れなのか、曇りなのか、雨なのか。そしてどういう動きをすべきか、というフィードバックまで出せます。実際にこれを作り、いま運用しています。
各メンバーの負担は、この定例で自分の案件を口頭で話すことだけ。事前準備はゼロです。ユニットリーダーは会議で聞いた内容を頭に入れておけばいいし、このレポートを読み上げるだけでも上位報告ができます。しかもHTMLは毎週残っていくので、時系列の変化——ちゃんと良くなっているのか、悪化しているのか——もAIに見させて確認できます。単発の資料ではなく、変遷が資産になるのです。
見えてきた「AIファーストの会社」のTo-Be像
正直に言うと、まだ道半ばです。ユニット全体のフォルダと個別案件のフォルダの整合が取り切れていない部分がありますし、AIファーストではない従来型のプロジェクト進行のほうがまだ大部分を占めています。
でも、やるべきことははっきり見えています。親フォルダと子フォルダの構造を定め、命名規則を揃え、「文字起こしを必ず残す」運用ルールを整備する。それが全社に行き渡れば、AIがほぼすべてのプロジェクトをサポートでき、全体状況の把握が誰にでもスムーズにできる「AIファーストのプロジェクトフォルダ群」が出来上がります。
非エンジニアへのポイント: 個別案件で型ができたら、展開はコピーするだけ。報告資料は「作る」のをやめて、データと口頭報告から「生成」する。
第6章 チーム展開とトークン運用の勘所
※この章は、半年使い倒した先の「量」との付き合い方の話です。これから始める方は読み飛ばして、第7章やおわりにへ進んでも大丈夫です。
「人がやる必要ない」は、使えば勝手にわかる
こうした取り組みと並行して、セールスチームの中でも運用の共有が進んでいきました。スキル（HTML資料生成など）は1か所に集めてチームで共有し、そのまま資料作成に使ってもらう。バッチ処理をそのまま渡して使ってもらうこともあります。
面白いのは、使い始めたメンバーがそれぞれ自分なりの自動化バッチを作り始めることです。少しずつ使っていると「これ、人がやる必要ないな」が自分の業務の中でどんどん見えてくる。いまは私と同じユニットであるセールス4名全員がClaude Codeを日常的に使い、所属する本部の中でも、関連メンバーへの情報共有が進んでいます。効果をきちんと数字で測るのはこれからですが、メンバーからは「この仕組みがないと、残業しても業務が終わらない」という声が出るまでになっています。
チームのトークン使用量はかなり多くなってきたので、セールス4名はチームプランの中でも使えるトークン数が多いプレミアムシートに切り替えました。考え方はシンプルで、良いモデルをできるだけ多く回し、上限に引っかかる体験まで含めて肌感を掴むことを優先しています。どのくらい使うと上限に当たるのか、当たったらどう節約するのかという勘所は、使い切ってみて初めてわかります。
5時間の上限に2回ぶつかってわかった、モデルの使い分け
私自身、最上位モデルを基本にして回していた時期に、5時間の利用上限に2回到達しました。参考までに、Claude Codeの利用制限にはいくつかの区分があります（2026年7月時点の仕様です。最新は公式ドキュメントを確認してください）。
- 5時間ウィンドウの制限: 全モデル共通。軽いモデルに切り替えても回避できない。並列でサブエージェントを大量に同時起動すると一気に逼迫する
- 週次の全体枠: 7日間ローリングでの総量
- 最上位モデルの専用枠: 週次の全体枠とは別に、最上位モデルの利用分だけ二重にカウントされる
こうした制限を前提に、高い品質を保ちながら使用量をどう最適化するか。私が個人で試している工夫の柱はモデルの役割分担です。
- 司令塔（メインセッション）: 最上位モデル。プランニング、評価・フィードバック、顧客提出物の最終レビューといった「高難度の判断」に投資する
- 実行役（サブエージェント）: 中位モデル。仕様が固まった実装・生成・修正を担う
- 機械処理: 軽量モデル。調査、抽出、変換、転記
- 原則: 並列で大量に走らせる処理に最上位モデルを流さない。「良いモデルはデフォルトで使うもの」ではなく「重要な判断に投資するもの」
役割分担のほかにも、いくつか試しています。コンテキスト使用率とレート残量の常時表示（しきい値で警告）、週次の使用ペースを毎朝Slackに自動通知してペースが速い日はメインのモデルを一段軽くする運用、ファイルを何本も読む調査をサブエージェントに委譲して手元の読み込み量を温存する設定、といったものです。何が正解かはまだ分かりません。外部の情報も参照しながら、試行錯誤を続けている途中です。
複数セッションを並行で回す
慣れてくると、Claude Codeのセッションは1つでは足りなくなります。複数プロジェクトの夜間バッチや資料生成を裏で走らせながら、手前では別の作業をする。常に複数セッションが並行で動いている状態が日常になりました。
並行するセッションの管理には、Claude CodeのAgent viewという機能を使っています。複数のセッションを1つの画面に並べて、どれが動いていて、どれが完了し、どれが入力待ちかを一覧で把握できるので、ウィンドウを行ったり来たりして状況を確認する負担がかなり減ります。
地味だけど必須 — 通知に顧客名を書かない
あわせて整えたのが通知まわりです。どのセッションが完了したか・入力待ちかをWindowsのトースト通知で受け取る仕組みをClaude Codeと一緒に作りました。ひとつ工夫があって、通知の本文には案件名や顧客名を一切入れない固定文言にしています。会議中に画面共有をしていても、通知から情報が漏れないようにするためです。地味ですが、業務で使い倒すなら必須の作り込みだと思います。
長い作業の「記憶」を守る — compact対策
もうひとつ、使い込むと必ずぶつかるのがコンテキストの上限です。Claude Codeは会話が長くなると履歴を自動で要約・圧縮（compact）するのですが、このとき「何をしたか」という作業ログは残る一方で、「どの案を採用し、どの案をなぜ却下したか」という判断の構造が消えてしまうことに気づきました。圧縮後のAIが、一度却下したはずの案を平然と再提案してくるのです。
対策として、圧縮の前に判断構造（採用案・却下案と理由・現在のフェーズ・制約）を別ファイルに保存しておき、圧縮後はまずそれを読み直してから作業を再開する、という運用ルールを仕組み化しました。AIとの長い協働では、AIの「記憶の限界」を前提にした設計が要る。これも使い倒して初めてわかったことです。
非エンジニアへのポイント: 上限に当たるのは失敗じゃなくて学習。どこで消費が激しいかの肌感は、使い切った人にしか残らない。
第7章 自分自身も自動化する — 作業ログ・勤怠・自己改善
「自分の業務は本当に最適化されているか」を測る
組織への展開と並行して、いま個人としては自分のClaude Code活用をさらに深めるチャレンジをしています。テーマは「自分の業務は本当に効率化・最適化されているのか」を測ることです。今日何をすべきか、習慣的に何をすべきかを考えるにも、まず自分の実態がデータで見えている必要があります。
そこで作ったのが、日次の業務ログを自動で全部残す仕組みです。Windowsの作業ログ、カレンダーの情報、それに一部の画面キャプチャが取れれば、「この時間からこの時間はこういう作業をしていた」がかなり高い精度で復元できることがわかりました。運用はこうです。
- 端末上で作業ログが常時記録され続ける
- 退勤前にスキルを1回実行する（Claude Codeにコマンドを1つ打つだけ）
- その日の業務ログが整理・構造化されたかたちで残る
さらに、勤怠の入力もこのログに則って半自動化しています。整理されたログをもとに弊社の勤怠管理システムへ自動で入力し、最後に自分が目視確認して送信ボタンを押すだけ。ここまで仕組み化できている状況です。
これを続けると、1週間・1ヶ月の単位で「自分がどこに稼働をかけているか」「作業時間の傾向はどうか」が見えてきます。見えれば改善できる。「ここはもっとこうすべきでは」という観点が自分に対して持てるようになる。プロジェクトに適用したAIファーストを、自分自身にも適用する取り組みです。
AIに「自分の癖」を学習させる実験
もうひとつ試しているのが、セッション履歴の活用です。Claude Codeとのやり取りは履歴として全部自分の端末に残っています（数えてみたら、この半年で約3,000回のプロンプトを投げていました）。その履歴を見ると、自分がAIに対してどんな修正依頼を繰り返しているか——つまり自分の癖——がテキストとして見えてきます。
同じような修正依頼が頻繁に出ているなら、それはルール化すべきものです。そこで、履歴から繰り返しの修正指示を自動で検出して候補として蓄積し、週次で自分がレビューして採用したものだけを設定ファイル（CLAUDE.md）のルールに昇格させる仕組みを作りました。収集は全自動、ルール化は承認式です。一度ルールになれば、次からは言わなくても私の癖を踏まえて対応してくれる。AIとのやり取りが、そのままAIへの指示書を育てていく。このフィードバックループがどこまでうまく回るか、いま実験を進めているところです。
1人月で回せる案件の幅を、どこまで広げられるか
効果を数字で示せる段階にはまだありませんが、体感でははっきりしています。いまと同じアウトプットを人手だけで出そうとしたら、残業を重ねても終わりません。品質を保ったまま仕事が回り、管理にかける工数も減った実感があります。
まだ使い始めて半年です。新しいAIツールもどんどん出てきます。世の中の事例を目にしたら自分でも試す、を繰り返しながら、人がやる領域（考える、作業する）をどんどん削っていく。基本はAIにすべて裏で任せ、任せる量を増やし、品質を維持したまま、自分の1人月で回せる案件の幅を、案件創出もデリバリーも含めて広げていく。今まで人が1人月でやれた以上のアウトプットを作ることを心がけて回していくつもりです。
業務利用の前提について
ここまで紹介した運用は、案件のファイル・会議の音声・作業ログといった機微な情報をAIに扱わせるものです。同じことを業務でやる場合に、前提として押さえておきたいポイントを最後に整理しておきます。
- 生成AIツールを業務で使ってよいか、どの範囲まで任せてよいかは、まず自社のポリシーの確認から
- 会議の録音・文字起こしは、参加者への事前の説明と同意が前提です。外部の文字起こしサービスを使う場合は、自社のセキュリティポリシーと顧客との契約上の制約の確認を（第3章にも書いたとおりです）
- 顧客情報を含むフォルダの置き場所やアクセス権限は、自社の情報管理ルールに沿わせます
- バッチや勤怠入力のような自動処理の結果は、人が最終確認してから使います。AIの出力をそのまま重要な判断や提出物に使わないこと
- なお、本文で紹介した構成や名称は、公開にあたり一部簡略化しています
非エンジニアへのポイント: まず自分の稼働をデータにする。見えないものは改善できない。
おわりに — 非エンジニアこそ、いま始めるべき理由
Claude Codeは世の中的には開発・コーディングの文脈で語られることが圧倒的に多いですが、半年使ってきた正直な実感として、セールスやPMのような非エンジニアこそ積極的に使うべきです。無駄な業務をなくし、品質を保ったまま、自分ひとりで回せる仕事の量を拡大できる。その恩恵が一番大きいのは、開発が本業ではない私たちの側だと思います。
余談ですが、最近は個人のアカウントも契約して、家計やファイナンス、キャリアといった私生活のプランニングも同じ仕組みで運用しています。続けているとClaudeが自分の状況を把握した上での相談相手になってきて、「常に何でも相談できて、自分のことを一番わかってくれる相手が横にずっといる」——それが月1万円台で手に入る。仕事で始めたAIファーストが私生活でも同じ構造で効くのは、使い込んだからこその発見でした。
半年でうまくいかなかったこと5つ
いいことばかり書いてきたので、失敗も一箇所にまとめておきます。
- PowerPointの直接生成は見栄えで断念（第4章）
- 画像でのスライド生成は、きれいだが微調整できず・AIが再利用できず（第4章）
- GitHub Projectsの自動タスク管理は、タスクが細かすぎて数週間で形骸化（第3章）
- 5時間の利用上限に2回到達。並列で豪快に回しすぎた（第6章）
- compact（自動圧縮）後のAIが、却下したはずの案を再提案してくる問題に遭遇（第6章）
どれも「自動化は『できる』と『運用が回る』の間に溝がある」の言い換えです。この溝は、使い倒した人から順に越えられるようになります。
ツールは変わる。変わらないのは「情報資産」
最後に、この記事で一番伝えたいことです。
Claude Codeは正直、まだとっつきづらいツールです。黒い画面（ターミナル）に抵抗がある人も多いでしょう。でも、AIが同僚のようにPC作業を代行してくれる「Claude Cowork」のような、GUIで使いやすいツールもすでに登場していて、数年以内には、もっと簡単に、わかりやすく使えるものが次々に出てくるはずです。
つまりツールは必ず変わります。モデルも賢くなり続けます。でも、それらが食べる「大元のドメイン情報」は変わりません。どの会議で誰が何を話し、何を合意してきたのか。プロジェクトの資料がどこにどう置かれているのか。この情報資産だけは、その場で残さなければ二度と手に入らず、整備には時間がかかります。
だから、組織としての順番はこうです。
- 文字起こしを全部残す文化を、今日から作る（誤字だらけでいい、話者不明でいい、とにかく残す）
- AIが読める形にプロジェクトフォルダを整える（AIに設計させればいい）
- まずClaude Codeで始めてみて、どれだけ楽になるかを実体感する
- 「これは人がやらなきゃ」という思い込みを、体感で一つずつ潰していく
まずは今日、30分だけ — 個人でできる最初の一歩
組織を動かす前に、ひとりで今日できることを置いておきます。
- Claude Codeをインストールする（公式の手順どおりで15分ほど。最初の関門は「黒い画面に慣れる」、それだけです）
- 自分の担当案件のフォルダを1つ、ローカルに同期する（きれいにしなくていい。汚いままで大丈夫です）
- そのフォルダでClaude Codeを起動して、最初の一言を打つ（音声入力でもOK）: 「このフォルダは〇〇案件の資料置き場です。中身をざっと確認して、どんな状況のプロジェクトか教えてください」
- 気に入ったら、CLAUDE.mdを作ってもらう: 「このプロジェクトをあなたと一緒に回していきたい。今の中身を踏まえて、CLAUDE.mdとフォルダ構成を提案してください」
- 次の会議から、文字起こしをそのフォルダに放り込む
ここまでで、この記事の第1〜2章と同じ場所に立てます。あとは同じ道です。
人が手間をかけてAIが理解しやすい状態を作る。この運用転換をどれだけ早く始められるかが、数年後の組織の差になると本気で思っています。ツールが変わっても持ち運べる資産を、いまから貯め始めてください。
難しいことは、本当に、何もありません。
