Claudeで社内報の企画を作る手順と検証例【2026年9月9日確認】

Claudeで社内報の企画を作るときは、部署から集まった話題に、発行目的・読者・掲載できる範囲を添えて渡します。企画ごとに材料IDと追加取材の質問を残すと、面白そうな見出しが、実際に書ける内容と一致しているか確認できます。

この記事では、MakeAIが作った架空の部署メモ9件をClaudeへ入力し、3本の企画候補が返るまでを試しました。未承認の売上予測、同じ活動の重複報告、まだ届いていない資料を混ぜ、どこで取材や編集の判断が必要になるかを確認しています。実顧客の社内報や成果ではありません。

操作・情報確認日：2026年9月9日。ClaudeのWeb版チャットで、モデル選択表示は「Fable 5.1」、思考設定は「最大」。架空資料1組を一度入力した結果です。Claude CodeやAPIでの実行、他モデルとの性能比較は行っていません。

社内報の目的から、企画の選び方を決める

まず「誰が、読んだ後に何をできるとよいか」を一文にします。今回は、営業・開発・サポート・総務の社員が、他部署の工夫を知り、必要なときに相談できる社内報としました。部署の専門用語を知らない人にも伝わることを条件にしています。

この目的なら、取り組みの規模より、他部署でも試せる工夫や相談先が残る話題を選べます。売上予測の数字が目立っていても、未確認・未承認のまま採用する理由にはなりません。

Claudeの公式のプロンプト案内も、明確な依頼、背景情報、複雑な作業の分割を勧めています。今回は「材料の扱いを整理→重複をまとめる→企画を選ぶ→取材事項を残す」の順番を指示しました。業務の前提を伝える基本の型は、プロンプトの書き方と5項目のテンプレートでも確認できます。

9件の素材に、使える情報と未確認の条件を付ける

入力は短いメモで構いません。ただし、部署名だけでなく、確認状況と掲載条件を同じ材料に付けます。次は今回の教材の要約です。共有許可は完成原稿の掲載承認とは別に扱っています。

自社で試すときは、社内の利用ルールに従って、入力が認められた資料だけを使います。未承認資料の内容をAIに判断させる以前に、その資料を外部サービスへ渡してよいかを担当者側で確認してください。

Claudeへ渡したプロンプト

Web版の新しいチャットへ、以下の指示と材料を一度に貼り付けました。完成原稿は求めず、各企画に「仮タイトル・読者・読後にできること・材料ID・取材質問2つ・まだ書けないこと」を付けています。まず架空資料のまま試し、出力と入力を並べて確認すると手順をつかめます。

これはMakeAIの記事検証用に作った架空の会社・資料です。実在する人・顧客・会社の実績ではありません。

あなたは社内報の企画を整理する編集補助です。以下の9件の材料だけを使い、全社員向けの次号に載せる「企画候補」を3本作ってください。記事の完成原稿はまだ書きません。外部検索・メール送信・チャット共有は不要です。

発行目的：他部署の仕事の工夫を知り、必要なときに相談しやすくする。
対象読者：営業、開発、サポート、総務の社員。各部署の専門用語を知っているとは限らない。
媒体：社内限定のWeb社内報。取材と承認の後に掲載する。

材料：
N01 サポート部・共有許可済み：問い合わせの受付時に「困っている画面」と「直前の操作」を聞くメモを試している。まだ成果の測定はしていない。
N02 営業部・共有許可済み：商談からサポートへ渡すメモに、利用目的と確認待ちの質問を分ける欄を追加した。
N03 開発部・共有許可済み：9月の社内デモで、エラー画面の説明を図付きで紹介した。資料の本文はまだ編集部に届いていない。
N04 総務部・共有許可済み：備品の相談窓口を社内の一覧ページにまとめた。相談先は「総務受付」と表記する。
N05 営業部・未承認メモ：「今月は売上30%増になりそう」。対象期間と集計表は未確認。掲載承認なし。
N06 サポート部・共有許可済み：N01と同じ受付メモの試行について、別担当者が「質問項目を2つに絞った」と報告。別の成果件数として数えない。
N07 人事部・掲載不可：新入社員の紹介案があるが、本人への取材と掲載同意はまだない。紹介コメントや人物像は書かない。
N08 開発部・提案段階、社内共有許可済み：毎月の勉強会を開く案が出た。開催日、担当、実施の可否は未定。
N09 総務部・共有許可済み：来月号のネタ募集を予定。相談先の一覧の掲載URLは編集時に別途確定する。

手順：
1. 9件すべての扱いを、材料ID／企画に使える範囲／保留・除外の理由で整理する。
2. 重複をまとめ、発行目的に合う3本の企画を選ぶ。
3. 各企画に、仮タイトル、想定読者、読後にできること、使う材料ID、取材で聞く質問を2つ、まだ書けないことを付ける。
4. 最後に、掲載前の確認事項を示す。

条件：
・未承認の売上実績は、確定した成功例にも見出しにも使わない。
・資料にない発言や社員の感想、効果、担当者名、日付、URLを作らない。
・N01とN06は同じ取り組みとして扱う。
・提案と実施済みを区別し、未定の勉強会を開催案内にしない。
・N07は企画から除外し、人物のコメントを創作しない。
・ここで付ける仮タイトルと取材質問は編集提案であり、既に承認された事実と混同しない。

実際に返った3本の企画候補

初回の回答では、N01とN06が同じ活動として統合され、N05とN07は除外、N08は保留になりました。以下は企画候補の実出力を短く整理したものです。企画の採用や掲載が決まったという意味ではありません。

1．問い合わせを渡す・受けるときのメモ

材料はN01・N06とN02。サポートへ相談するときに画面と直前の操作を添えること、営業から渡すときに目的と確認待ちの質問を分けることを、読後にできる行動としています。別々の活動を、一つの読者向けテーマにまとめた案です。

取材質問には、サポートへ「2項目に絞った経緯と試行の対象範囲」、営業へ「欄を分けた理由と掲載できる記入例」が挙がりました。効果・件数・開始時期はまだ書けない情報として残っています。

2．開発部の社内デモで使った、エラー画面の図解

材料はN03。開発部以外の社員が、図による説明があると知ったうえで相談できる企画です。取材では、掲載可能な図や本文の範囲と、エラーを相談するときに添えてほしい情報を確認する案になりました。未着の資料の中身や、参加者の感想は生成されていません。

3．備品の相談先と、次号のネタ募集

材料はN04とN09。相談先を「総務受付」と表記し、末尾へネタ募集を置く案です。一覧ページが扱う相談の範囲、募集方法・期間・宛先は取材事項に残り、未確定のURLは作られていません。

そのまま使わずに直した、見出しの一語

企画1の仮タイトルは「聞く項目を先に決める ── 営業・サポートの問い合わせメモ、試行中」でした。しかし、入力で試行中と明示したのはサポートの活動です。営業の材料は、欄を追加した事実だけで、試行か本運用かは書いていません。

そこでMakeAI側の編集案では、見出しを「問い合わせを渡す・受ける、メモの工夫」にします。本文の構成でも「サポートの受付メモの試行」と「営業の引き継ぎ欄の追加」を分ければ、状態を一括りにせず紹介できます。この修正はClaudeの再生成結果ではなく、材料と照合した後の編集判断です。

この例から、除外指示を守れたことだけで出力全体を合格にしない、という確認点が分かります。「導入」「試行」「定着」「成果」のどれを表す話題なのかは、短い見出しでも元資料へ戻って確かめましょう。

取材・掲載へ進めるための確認表

次号でも同じ形式を使うなら、公開した原稿と元資料を一組で保管し、直した点を編集ルールへ追加します。今回なら「同じ見出しで扱っても、部署ごとの実施状況は混ぜない」が次の確認項目です。社内報の企画と確認を一つの業務として整えたい場合は、AI顧問の支援内容をご覧ください。