みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 みなさんは、AWS Japan が開催しているイベントをどこで探していますか。AWS のイベント情報は英語のものが多く、日本語で参加できるものを見つけにくいと感じている方もいるのではないでしょうか。そんなときに便利なのが AWS Experience のイベント一覧ページ です。開催地を日本に絞って表示できるので、国内で開催されるセミナーやイベントだけをまとめて確認できます。「こんなイベントがあったんだ」という発見があると思いますので、ぜひ一度のぞいてみてください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年9月7日週の主要なアップデート 9/8(火) Amazon S3 Object Lock がイベントホールドによる可変リテンションをサポート Amazon S3 Object Lock に可変リテンションが追加されました。S3 Object Lock は、オブジェクトに「この日までは削除も上書きもできない」という保持期限日を付けて WORM 保護する機能です。この期限日は後から延ばすことはできますが、手前に戻すことはできません。そのため「契約終了後 5 年保持」のように書き込み時点で終了日が決まらない要件では、これまでは期限日を長めに置いて余分な保持コストを払うか、短めに置いて期限切れ前に延長し続けるかの 2 つの方法がありました。今回の可変リテンションでは、オブジェクトに「イベントホールド」の ON と保持期間 (例: 5 年) を設定します。ホールドが ON の間、S3 は期限日を「現在時刻 + 5 年」として動的に前進させ続けるため、利用者が延長操作を繰り返す必要はありません。契約終了や監査完了などのイベントが起きた時点でホールドを OFF にすると、その時刻を起点に「解除時刻 + 5 年」で期限日が固定され、そこから指定期間の WORM 保護が続きます。全リージョンで追加料金なしで利用できます｡ Amazon EMR が旧リリースから移行中の顧客向けに追加費用なしでサポートを延長 Amazon EMR は、旧リリースから現行リリースへ移行中の顧客に対し、追加費用なしでサポート期間を延長しました。EMR 5.36 および 6.6 から 6.15 は 2027 年 6 月 30 日までベストエフォートで重大なセキュリティ修正を受けられ、EMR 7.0 から 7.10 は 2027 年 8 月 31 日まで Standard Support 相当のサポートを受けられます。延長を受けるには、移行計画を添えて AWS Support に連絡する必要があります。Amazon RDS や Amazon EKS の Extended Support が有償であるのに対し、EMR のこの延長は無償である点が特徴です。EMR on EC2、EMR on EKS、EMR Serverless のすべてのデプロイモデルと全リージョンが対象です。 Amazon API Gateway がバックエンド統合向けの mutual TLS をサポート Amazon API Gateway の REST API が、バックエンドへの接続時に AWS Certificate Manager (ACM) の証明書をクライアント証明書として提示できるようになりました。従来は API Gateway が生成する自己署名証明書しか使えませんでしたが、既存 PKI からインポートした証明書や AWS Private Certificate Authority が発行した証明書を利用できます。ACM 上で証明書が更新・再インポートされると API Gateway が自動的に反映するため、ステージの再デプロイやダウンタイムは発生しません。既存のインバウンド mTLS と組み合わせることで、クライアントから API、API からバックエンドまでの両区間で相互認証を構成できます。 OpenAI GPT-6 Astra が Amazon Bedrock で一般提供開始 OpenAI の最新かつ最上位モデルである GPT-6 Astra が Amazon Bedrock で一般提供を開始しました。最大 100 万入力トークンのコンテキストウィンドウ、推論能力の向上、コンピュータ操作・ブラウザ操作機能を備え、自律エージェントの構築や大量文書の分析に使えます。Bedrock API から直接呼び出せるほか、ChatGPT Work と Codex の推論先として Bedrock 上の本モデルを指定できます。あわせて、ChatGPT Work のブラウザ操作を業務アプリケーションに広げるエンタープライズプラグインも発表されました。IAM によるアクセス管理、CloudTrail によるモデル呼び出しの監査など、既存の AWS の統制がそのまま適用されます。 9/9(水) Amazon Quick デスクトップアプリが macOS と Windows で一般提供開始 Amazon Quick のデスクトップアプリが macOS と Windows で一般提供を開始しました。ブラウザ版では扱えなかったローカルファイルをアップロードなしで直接分析でき、カレンダー、メール、ビジネスアプリにバックグラウンドで常時接続します。会話、コンテキスト、エージェントはデスクトップとモバイルアプリ間で同期され、PC を閉じた後もエージェントはバックグラウンドで実行を継続します。東京リージョンを含む 7 リージョンで利用でき、AWS SLA と企業向けのガバナンス・管理機能を備えます。 AWS Lambda が Lambda Managed Instances で Graviton5 搭載 EC2 インスタンスをサポート AWS Lambda の Lambda Managed Instances が、最新世代 AWS Graviton5 プロセッサを搭載した C9g、C9gd、M9g、M9gd インスタンスに対応しました。Graviton5 は Graviton4 比でコンピュート性能が最大 25% 向上しており、Web アプリケーションで最大 35%、データベースで最大 30%、機械学習推論で最大 35% の高速化が見込めます。capacity provider 作成時にインスタンスタイプとして Graviton5 世代を明示指定できるほか、default 設定のままでも関数のアーキテクチャ、メモリサイズ、メモリ対 vCPU 比率に基づいて Lambda が Graviton5 インスタンスを選択候補に含めます。料金は EC2 インスタンス料金 + 15% の管理料金というモデルのため、性能向上がそのままコスト効率の改善につながります。 AWS Lambda が Lambda Managed Instances で 90 分の関数タイムアウトをサポート AWS Lambda は、Lambda Managed Instances 上で実行する関数について、非同期呼び出しや､Amazon SQS･DynamoDB Streams･Kinesis Data Streams などのメッセージキューと連携するイベントソースマッピング呼び出しの関数タイムアウトを最大 90 分 (5,400 秒) まで設定できるようになりました。従来の上限である 15 分 (900 秒) の 6 倍となります。使い方の例をいつくかあげると､メディアトランスコード、モンテカルロシミュレーションなどの金融計算、AI 推論、バッチ処理といった使い方が想定できます｡同期呼び出しのタイムアウト上限は従来どおり 15 分です。 9/10(木) Amazon EVS が追加リージョンで利用可能に Amazon Elastic VMware Service (Amazon EVS) が、大阪リージョン、台北リージョン、スペインリージョン、テルアビブリージョンの 4 リージョンで利用可能になりました。Amazon EVS は VMware Cloud Foundation (VCF) を自身の VPC 内の EC2 ベアメタルインスタンス上で直接実行できるサービスで、今回の拡大により利用可能リージョンは東京を含む 22 リージョンになりました。VCF 9.0 / 9.1 サポートを含む既存のすべての機能が新リージョンでも利用でき、データレジデンシー要件への対応や、東京・大阪の 2 リージョンを使った国内ディザスタリカバリ構成が可能になります。 AWS Elemental Inference がライブ動画からコンテキストメタデータをリアルタイム生成 AWS Elemental Inference が、ライブ配信中の映像を AI がその場で分析し、「今どんな場面か」を表すデータを自動生成できるようになりました。配信用の映像変換と並行して数秒遅れで映像を読み取り、広告業界の共通分類による場面カテゴリ (スポーツ、料理など)、広告を出すべきでない場面のフラグ (事故映像など)、映っている物と動作、場面の説明文を出力します。映像内の「ここから CM」の目印に AWS Elemental MediaLive がこの分析結果への参照を追記し、広告を差し込む AWS Elemental MediaTailor が直前の場面情報を取得して広告選択サーバーへ条件として渡すため、連携プログラムを開発せずに場面に合った広告配信ができます。過去映像の検索用データ付与にも使えます。 Amazon OpenSearch Serverless が v0 by Vercel で利用可能に AI コード生成プラットフォームである v0 by Vercel 上で、Amazon OpenSearch Serverless を利用したフルスタックアプリケーションを構築できるようになりました。自然言語プロンプトを入力するだけで、v0 がアプリケーションコードの生成、OpenSearch Serverless コレクションの自動プロビジョニング、データのインデックス登録、環境変数の設定までを行います。全文検索と RAG 向けベクトル検索の両方に対応し、バージニア北部、東京、大阪を含む 17 リージョンで利用できます。新規または既存の AWS アカウントに紐付けて利用でき、OpenSearch Serverless の利用料金は AWS から直接請求されます。 Amazon API Gateway が 1 MB の実行ログと設定可能な配信先をサポート Amazon API Gateway の REST API 実行ログ (execution logs) が、CloudWatch Logs delivery の仕組みに対応しました。従来は API Gateway 管理の CloudWatch Logs ロググループのみに配信され、ログイベントは 1 KB で切り捨てられていましたが、今回のアップデートで最大 1 MB のログイベントを、自分で管理する CloudWatch Logs ロググループ、Amazon S3 バケット、Amazon Data Firehose ストリームに配信できるようになりました。複数の配信先への同時配信にも対応し、たとえば S3 へは Apache Parquet 形式で長期保存しつつ、CloudWatch Logs へは JSON 形式でリアルタイムアラート用に配信するといった構成が組めます。AWS GovCloud (US) を含む、API Gateway REST API が利用できるすべてのリージョンで利用できます。料金は vended logs 料金が適用されます。 9/11(金) AWS DevOps Agent が Slack との双方向通信に対応 AWS DevOps Agent が Slack との双方向通信に対応しました。従来は調査結果を Slack チャンネルに投稿する一方向通知のみでしたが、今回のアップデートにより、プライベートチャンネルで AWS DevOps Agent アプリを @メンションするだけで調査の開始・確認・誘導ができるようになりました。エージェントの調査結果、チームが提供したコンテキスト、推奨アクションが 1 つのスレッドに集約されるため、インシデント対応中のツール切り替えが不要になり、トリガーから緩和までの記録がそのまま監査証跡として残ります。本機能は AWS DevOps Agent が利用可能なすべての商用リージョン (東京リージョンを含む 11 リージョン) で提供されます。ドキュメント上のリリース日は 2026 年 9 月 1 日です。 AWS Lambda が Amazon S3 Files のダイレクトリード設定に対応 AWS Lambda で、Amazon S3 Files のダイレクトリード (direct read) を関数ごとに有効化・無効化できるようになりました。Amazon S3 Files は、S3 バケットの中身を Lambda 関数から通常のファイルのように読み書きできる機能で、S3 の手前に高速なストレージ層 (high-performance storage) を持ちます。通常はこの層を経由して読むため小さな読み取りの応答が速く、「ダイレクトリード」はこの層を飛ばして S3 バケットから直接読む方式で、大きなデータをまとめて読む際の転送量を稼ぎやすくなります。これまではメモリ 512 MB 以上の関数だけ自動でダイレクトリードが有効になり、利用者は選べませんでしたが、今回からメモリサイズに関係なく関数の設定で切り替えられます。ダイレクトリードには実行ロールに s3:GetObject と s3:GetObjectVersion の権限が必要で、失敗時は自動で高速ストレージ経由に戻ります。追加料金はなく、ニュージーランドリージョン、バーレーンリージョン、UAE リージョンを除くすべての商用リージョンと AWS GovCloud (US) で利用できます。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

はじめに — この記事でお話しすること こんにちは。Insight Edgeで営業を担当している塩見和真と申します。 この記事は、非エンジニアの私が、この半年間Claude Codeを実際の案件運営に使ってきた実践記です。プロジェクトフォルダの設計から、会議文字起こしの自動ナレッジ化、提案資料や報告資料の生成、チームへの展開まで。うまくいったことも、数週間で形骸化してしまった失敗も、時系列でそのまま書きます。 なお、 この記事自体も、半年の取り組みを音声入力で思い出しながら話し、その文字起こしを生成AIに整形させて作ったものです （実際に口頭で話した時間は、合計15〜20分ほどだと思います）。 図版も生成AIで作っています 。本文で紹介する「音声で全部吐き出して、AIに形にさせる」というやり方そのもので出来ています。 結論から言えば、 難しいことは何もしていません 。フォルダ構成に気をつけて、ターミナルに慣れて、テキストでAIとやり取りする。それだけです。非エンジニアの方が「自分にもできそう」と思える道しるべになれば嬉しいです。 要約 : 1つの案件を対象に、AIが常にプロジェクトの状況を把握している状態をフォルダ設計と、AIへの指示書（CLAUDE.md）で作り、会議の文字起こしを毎晩自動でナレッジに変える仕組みを整えました。その上で、資料作成をAIに任せるまでの試行錯誤（PowerPoint→画像→HTML）を経て、チームの週次報告も「作る」から「生成する」形に変えていきました。本文では、この半年でうまくいかなかったこと5つと、今日からできる最初の一歩までを紹介します。 図1: この記事の全体像 — 営業のClaude Code活用、半年の道のり はじめに — この記事でお話しすること 第1章 すべての始まり — 1案件での「AIファースト」実験 ChatGPTやGeminiとは「別物だ」と感じた一点 AIファーストの思想 — 「AIがプロジェクト情報を漏れなく理解している」を前提にする 現実 — ファイルは2つのクラウドに散らばり、フォルダは汚い ベースにSharePointを選んだ理由 第2章 AIが読めるフォルダを、AI自身に設計させる CLAUDE.md — Claude Codeの「最初に必ず読まれる指示書」 できあがったフォルダ構成 半年運用してわかった「本当に大事な3つ」 過去の情報も可能な限り取り込む 第3章 会議情報を毎晩、自動でナレッジに変える 「都度インプット不要」が確認できた瞬間 プロジェクト情報の大部分は、会議で生まれて消えていく 自動化もClaude Codeに作らせる 文字起こしは「いま残さないと二度と手に入らない」資産 タスク管理の実験と、正直な失敗談 第4章 資料作成 — PowerPoint→画像→HTMLへの試行錯誤 「アウトプットもAIが作る」までがAIファースト まずMarkdownで骨子を作る（どの方式でも共通） スライドの型と「1ページへの要求」を先に決めておく コラム: フィードバックは音声入力で 3方式を全部試して、2つ捨てた 方式1: PowerPointを直接生成させる → 見栄えで早期に断念 方式2: スライドを画像で生成する → きれいだが、直せない・再利用できない 方式3: HTMLでスライドを作る → きれい・直せる・AIが読める AIに資料を作らせるときの注意点 — 受け手の認知負荷は増えうる 正直な話 — 最初は気持ち悪かった おまけの武器 — 非エンジニアがプロトタイプを出す デリバリーだけじゃない — 案件創出（セールス）にも効く 第5章 プロジェクトを横に広げ、チームの報告を「コード化」する 展開は「フォルダをコピーする」だけ 親フォルダを作れば「経営者がClaude Codeを当てるだけ」の世界が見える よくある週次報告の風景を、HTMLレポート1枚に置き換える 見えてきた「AIファーストの会社」のTo-Be像 第6章 チーム展開とトークン運用の勘所 「人がやる必要ない」は、使えば勝手にわかる 5時間の上限に2回ぶつかってわかった、モデルの使い分け 複数セッションを並行で回す 地味だけど必須 — 通知に顧客名を書かない 長い作業の「記憶」を守る — compact対策 第7章 自分自身も自動化する — 作業ログ・勤怠・自己改善 「自分の業務は本当に最適化されているか」を測る AIに「自分の癖」を学習させる実験 1人月で回せる案件の幅を、どこまで広げられるか 業務利用の前提について おわりに — 非エンジニアこそ、いま始めるべき理由 半年でうまくいかなかったこと5つ ツールは変わる。変わらないのは「情報資産」 まずは今日、30分だけ — 個人でできる最初の一歩 第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と相談してできた構成がこちらです（実案件のものを一部簡略化しています）。 図2: フォルダは8つ作ったが、半年運用して本当に効いたのは3つだけだった 余談ですが、最初に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に通知。翌朝には「今の状況・論点・次にやること」が最新化されている 図3: 会議が終わったら文字起こしを置くだけ。あとは毎晩AIが勝手に更新する 半年間いろいろやってきましたが、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つあります。全部実験しました。先に結果を見せます。 図4: PowerPoint直接生成は早々に断念。最後に残ったのはHTMLだった 方式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に第三者視点で見させると、 ユニット全体として今が晴れなのか、曇りなのか、雨なのか 。そしてどういう動きをすべきか、というフィードバックまで出せます。実際にこれを作り、いま運用しています。 図5: 事前の資料作成ゼロで、週次報告が1枚のHTMLに集約される 各メンバーの負担は、この定例で自分の案件を口頭で話すことだけ。事前準備はゼロです。ユニットリーダーは会議で聞いた内容を頭に入れておけばいいし、このレポートを読み上げるだけでも上位報告ができます。しかも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日間ローリングでの総量 最上位モデルの専用枠 : 週次の全体枠とは別に、最上位モデルの利用分だけ二重にカウントされる こうした制限を前提に、高い品質を保ちながら使用量をどう最適化するか。私が個人で試している工夫の柱は モデルの役割分担 です。 司令塔 （メインセッション）: 最上位モデル。プランニング、評価・フィードバック、顧客提出物の最終レビューといった「高難度の判断」に投資する 実行役 （サブエージェント）: 中位モデル。仕様が固まった実装・生成・修正を担う 機械処理 : 軽量モデル。調査、抽出、変換、転記 原則: 並列で大量に走らせる処理に最上位モデルを流さない。「良いモデルはデフォルトで使うもの」ではなく「重要な判断に投資するもの」 図6: 良いモデルは「デフォルト」ではなく「重要な判断」に投資する 役割分担のほかにも、いくつか試しています。コンテキスト使用率とレート残量の常時表示（しきい値で警告）、週次の使用ペースを毎朝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で使いやすいツールもすでに登場していて、数年以内には、もっと簡単に、わかりやすく使えるものが次々に出てくるはずです。 つまり ツールは必ず変わります。モデルも賢くなり続けます。でも、それらが食べる「大元のドメイン情報」は変わりません 。どの会議で誰が何を話し、何を合意してきたのか。プロジェクトの資料がどこにどう置かれているのか。この情報資産だけは、その場で残さなければ二度と手に入らず、整備には時間がかかります。 図7: ツールは変わっても、貯めた情報資産は持ち運べる だから、組織としての順番はこうです。 文字起こしを全部残す文化を、今日から作る （誤字だらけでいい、話者不明でいい、とにかく残す） AIが読める形にプロジェクトフォルダを整える （AIに設計させればいい） まずClaude Codeで始めてみて、どれだけ楽になるかを実体感する 「これは人がやらなきゃ」という思い込みを、体感で一つずつ潰していく まずは今日、30分だけ — 個人でできる最初の一歩 組織を動かす前に、ひとりで今日できることを置いておきます。 Claude Codeをインストールする （ 公式の手順 どおりで15分ほど。最初の関門は「黒い画面に慣れる」、それだけです） 自分の担当案件のフォルダを1つ、ローカルに同期する （きれいにしなくていい。汚いままで大丈夫です） そのフォルダでClaude Codeを起動して、最初の一言を打つ （音声入力でもOK）: 「このフォルダは〇〇案件の資料置き場です。中身をざっと確認して、どんな状況のプロジェクトか教えてください」 気に入ったら、CLAUDE.mdを作ってもらう : 「このプロジェクトをあなたと一緒に回していきたい。今の中身を踏まえて、CLAUDE.mdとフォルダ構成を提案してください」 次の会議から、文字起こしをそのフォルダに放り込む ここまでで、この記事の第1〜2章と同じ場所に立てます。あとは同じ道です。 図8: この記事の要点 — 非エンジニアへのポイント7つ 人が手間をかけてAIが理解しやすい状態を作る。この運用転換をどれだけ早く始められるかが、数年後の組織の差になると本気で思っています。ツールが変わっても持ち運べる資産を、いまから貯め始めてください。 難しいことは、本当に、何もありません。

G-gen の本間です。Google Cloud のネットワーク機能である ハイブリッドサブネット について解説します。ハイブリッドサブネット機能を使うと、オンプレミスネットワークと VPC ネットワーク間で、同じ IP アドレス範囲を共有できます。 概要 ハイブリッドサブネットとは 料金 仕様 ルーティング ルートのアドバタイズ プロキシ ARP の使用 ハイブリッドサブネットを使用した VM 移行 制約事項と注意点 概要 IP アドレスの管理 使用できない環境・サービス オンプレミスネットワーク ルーティング 使用できない通信 概要 ハイブリッドサブネットとは ハイブリッドサブネット とは、Google Cloud の Virtual Private Cloud ネットワーク（以下、VPC ネットワーク）とオンプレミスネットワーク間で、同じ IP アドレス範囲を共有できる機能です。 通常、VPC ネットワークとオンプレミスネットワークを Cloud VPN（IPsec-VPN）や Cloud Interconnect（専用線）で接続する場合、IP アドレス範囲を重複させることはできません。しかし、ハイブリッドサブネットを使用することで、両環境にまたがる単一の論理的なサブネットを構成できます。 この機能は主に、オンプレミスのサーバーを Google Cloud へ移行する際、IP アドレスを変更せずに段階的に移行する目的で使用されます。 一般的に、クラウドへサーバーを移行する際には、サーバーの IP アドレスの変更を視野に入れるケースがあります。この場合、DNS レコードの更新、ファイアウォールルールの修正、依存するアプリケーションの設定変更なども付随して必要となります。 しかし、ハイブリッドサブネットを使用することで、オンプレミス環境と Google Cloud 環境を接続した状態でも同じ IP アドレス範囲をもつサブネットを Google Cloud に用意できるため、IP アドレスの変更が不要です。周辺システムの設定変更を最小限に抑え、Google Cloud 移行時のダウンタイムやリスクを低減できます。 参考 : About migrating to Google Cloud with Hybrid Subnets 料金 ハイブリッドサブネット機能自体の使用には、追加料金は発生しません。 VPC ネットワークのリソースや、送受信されるトラフィックに対する標準的な Google Cloud の料金のみが適用されます。 参考 : Virtual Private Cloud の料金 仕様 ルーティング ハイブリッドサブネットが有効になっているサブネットでは、パケットの転送動作が通常のサブネットとは異なります。 通常のサブネットでは、パケットの宛先がローカルまたはピアリングのサブネットルートと一致する場合、そのリソースへパケットを転送します。また、パケットの宛先が、実行中の Compute Engine VM（以下、VM）や内部転送ルールに関連付けられていなければ、パケットは破棄されます。一方、ハイブリッドサブネットでは以下のように処理されます。 パケットの宛先が一致する場合 パケットの宛先が、サブネット内で実行中の VM のネットワークインターフェースや内部転送ルールと一致する場合、通常のサブネット同様にそのリソースへパケットを配信します。 パケットの宛先が一致しない場合 パケットの宛先が、サブネット内の実行中の VM のネットワークインターフェースや内部転送ルールに一致しない場合でも、パケットは破棄されません。代わりに、ローカルまたはピアリングの静的ルート・動的ルートのネクストホップにパケットが転送されます。この動作により、クラウド上に存在しない宛先へのトラフィックを、オンプレミスネットワークへ正しく転送するための経路が確保されます。 参考 : About migrating to Google Cloud with Hybrid Subnets - Routing in the VPC network ルートのアドバタイズ Google Cloud へ移行されたサーバーへトラフィックを正しく引き込むため、Cloud Router からオンプレミスのルーターに対し、移行された個別の IP アドレスの /32 ルートをアドバタイズする必要があります。このルートは、Cloud Router にカスタムルートとして手動で設定する必要があります。 Border Gateway Protocol（以下、BGP）の最長一致の原則（Longest Prefix Match）により、オンプレミス側のより広い範囲のルート（ /24 など）よりも、Google Cloud 側からアドバタイズされた /32 ルートが優先されます。これにより、通信が正しく Google Cloud 上のサーバーに到達します。 プロキシ ARP の使用 サーバーが Google Cloud に移行された後も、オンプレミス側の他のクライアントは、対象サーバーが同じサブネット内にいると認識して ARP リクエストを送信します。このとき、オンプレミス側のルーターがプロキシ ARP で代理応答し、トラフィックを Cloud Router 経由で Google Cloud へ転送します。 このように、ハイブリッドサブネットを使用するには、オンプレミス側のネットワーク機器（ルーターなど）でプロキシ ARP を有効にする必要があります。 ハイブリッドサブネットを使用した VM 移行 ハイブリッドサブネットを使用して、オンプレミスから Google Cloud へサーバーの移行を行う際の、手順の概要は以下のとおりです。 オンプレミスのルーターが BGP をサポートし、プロキシ ARP を有効にできることを確認する Google Cloud 側で、オンプレミスと同じ IP アドレス範囲を持つ VPC サブネットを作成し、ハイブリッドサブネットルーティングを有効にする Cloud VPN や Cloud Interconnect を構成し、Cloud Router でオンプレミス環境との BGP セッションを確立する Migrate to Virtual Machines などの移行ツールを使用して、サーバーを Google Cloud に移行する 移行したサーバーの IP アドレス（ /32 ）を Cloud Router のカスタムアドバタイズルートに追加する VM の動作確認・試験を行う すべての移行が完了したら、ハイブリッドサブネットルーティングを無効にし、通常の VPC ルーティングに戻す ハイブリッドサブネット機能の有効化自体は簡単で、手順2のサブネット作成時に合わせて設定できます。またサブネットの新規作成時だけでなく、既存のサブネットに対しても、ハイブリッドサブネットを有効化できます。詳細な手順は以下のドキュメントを参照してください。 参考 : Prepare for Hybrid Subnets connectivity 参考 : Migrate workloads to Google Cloud with Hybrid Subnets 参考 : Disable hybrid subnet routing 制約事項と注意点 概要 当記事では、ハイブリッドサブネットの主要な制限を記載します。制限の詳細と、最新情報は公式ドキュメントを参照してください。 参考 : About migrating to Google Cloud with Hybrid Subnets - Limitations IP アドレスの管理 ハイブリッドサブネットには、IP アドレスの重複を自動的に防ぐ仕組みがありません。 そのため、オンプレミス環境と Google Cloud 環境で同じ IP アドレスが同時に使用されないよう、管理者が手動で厳密に IP アドレスを管理する必要があります。具体的には、Google Cloud 側への移行が完了したオンプレミスサーバーは速やかに停止するといった考慮が求められます。 使用できない環境・サービス ハイブリッドサブネットは、Google Cloud VMware Engine をサポートしていません。よってサーバーの移行先が Google Cloud VMware Engine の場合は、前述の移行手順を用いることはできません。 また Microsoft Azure や Amazon Web Services（AWS）とのプライベート接続で、ハイブリッドサブネットを用いることはできません。 オンプレミスネットワーク ハイブリッドサブネットで接続するオンプレミス側の対向機器となるルーターでは、プロキシ ARP の有効化と /32 ルートのアドバタイズの許容が求められます。 事前に使用する機器の仕様や設定を確認してください。 ルーティング ネットワークタグによる静的ルーティングの使用不可 Google Cloud の VPC ネットワークでは本来、Compute Engine VM のネットワークタグ機能を用いて静的ルートを設定可能です。しかし、ハイブリッドサブネットを使用している場合、ネットワークタグを使った静的ルーティングは使用できません。ハイブリッドサブネットでネットワークタグによる静的ルーティングを行っている場合、トラフィックが急増した際にパケットロスを引き起こす原因となります。 リージョンまたぎの通信は不可 ハイブリッドサブネット内のルーティングで宛先に通信を送る際、経路のネクストホップは、サブネットと同じリージョン内に存在する必要があります。異なるリージョンをネクストホップに指定した場合、パケットが破棄され、通信ができません。本来、Google Cloud の VPC ネットワークでは、本来であれば「東京リージョンのサブネットから、大阪リージョンの VPN ゲートウェイへ経路を向ける」といったルーティングも可能です。しかし、ハイブリッドサブネットでは仕様上、そのような設定はできないため注意してください。 使用できない通信 ハイブリッドサブネット環境では、IPv6 トラフィック、ブロードキャストトラフィック、マルチキャストトラフィックはサポートされていません。 また、Network Connectivity Center、ハイブリッド接続 NEG、ハイブリッド NAT とハイブリッドサブネットを併用することはできません。 本間 優太郎 (記事一覧) クラウドソリューション部 クラウドエンジニアリング2課 北海道在住 2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。 好きなことは子供と遊ぶこと、ゲームをすること。