発信より先に、記録する。Claude Code×GitHubで広報の仕事を博物館みたいに整えてみた話
こんにちは。クラシコム広報の白方です。
クラシコムでは、限られた時間のなかで本質的な仕事に向き合うために、社内のさまざまなチームがAIと一緒に仕事を進めています。私たち広報チームも、プレスリリースの原稿づくりや資料作成などで活用してきました。
そんな中、AIを推進するチームから、社内の研究的な取り組みとして、Claude CodeとGitHubを使って広報の仕事を進めてみたらどうなるか試してみてほしい、と提案があり、さっそく実験してみることになりました。
GitHubは、本来エンジニアがプログラムを書くために使う場所です。私は前職のIT企業で簡単な操作や使い方を教えてもらったことがあるので、まったく初めてではありませんでした。ただ、コードは書けませんし、AIと組み合わせて使うのも初めてです。
それでも、6月下旬から触りはじめて7月に本格的に動かしてみた結果、仕事の進め方ががらりと変わったように感じています。この記事では、私たちが1か月間、Claude CodeとGitHubを使ってどんなことをしてきたのかを、順番にまとめてみます。
自己紹介のアップデートに必要な情報を整備する
先に、動機の話を少しだけさせてください。
広報は、社内外のさまざまなステークホルダーとコミュニケーションし、適切なタイミングで自己紹介をアップデートし続けるような仕事です。同じことを同じように言い続けるのではなく、その時々の文脈に合わせて、自分たちが何者かを言い直していくことが大切ではないか、と考えています。
そんなふうに考えると、自己紹介をアップデートするための材料が手元にそろっていないと広報の仕事は始まりません。クラシコムの現在地だけでなく、これまで何をしてきたのか、世間にどう受け取られたのか、どんな数字につながったのかといった情報が、常に出し入れできる状態になるよう土台を整備する必要がありました。そのために、発信のしかたや仕事の効率化を考えるよりも先に、広報のデータアーカイブとして機能させることを目指して、Claude CodeとGitHubを使ってみることにしました。
6月下旬、チームで完結している仕事から粛々と
記録をたどると、最初にGitHubを使ってみたのは、2026年6月22日でした。私たちが触っても大丈夫なように、セキュリティ周りのチェックや環境はテックチームが整えてくれていたので、安心して使い始めたものの、最初はおそるおそる触り始めました。
最初に私が考えたのは、あえて全体の設計から手をつけないことでした。手元にある小さなプロジェクトや作業から箱となる場所をつくり、段階的に格納してみる。チームのなかで完結している仕事や、すでに完了しているプロジェクトなど、できるだけ他の人を巻き込まずに、小さく進められるところから着手してみました。
たとえば最初に行ったのは、以下のようなデータのアーカイブです。
メディア掲載実績
プレスリリース
議事録
自社Podcast番組の文字起こし
認知度調査
社史資料
こうしたデータ類は、これまでスプレッドシートやドキュメントなどの形式で、共有のGoogle Drive内にばらばらに置いてありましたが、GitHubを使うとひとつの場所に構造化して整理することができました。
またデータをGitHubに集約するのと合わせて自動で更新・蓄積していくための運用システムも構築していきました。
自動化も最初から行うのではなく、まずは手動で試してみて、うまくいったら少し自動化してみて、うまく回るようになったら社内にナレッジを共有できるようAIの「スキル」にしていくという、段階的なフローを踏みました。
そのあとは進行形で動いているプロジェクトや分析類もClaude Codeを通じて整理を進めていきました。
Podcast番組の配信データの分析
プロジェクトのスケジュール・タスク管理
広報の年間スケジュールと取材進捗の管理
プレスリリースの起案から入稿、社内外への告知までの半自動化
データはmdファイルやcsvファイルとしてGitHubに格納されていきますが、社内で共有するときにはhtmlや画像、Artifactという、つくった画面をそのままURLで共有できる機能を使って、ビジュアライズしています。そのときどきに必要なかたちに情報を柔軟に加工できるところが、スプレッドシートなどに比べると便利に感じています。
情報のアーカイブや自動更新化を進めていったあとは、さらに、他のチームへの共有も見据えて、クリエイティブの自動化にもトライしてみました。
プレスリリースや記事用の画像作成
ショート動画の作成
こうしたクリエイティブは最終的に細かな調整ができるように、調整ツールをつくるところまでセットで考えるように進めました。
たとえば、こんなふうに使っています
ここまでの作業も、うまくいったことばかりではありません。
使ってみて「この置き方だと探しづらいかも」「この指示だと上手く回らない」と気づいては修正する。そうした試行錯誤を繰り返し、気づけば6月下旬から8月頭までで、800件を超える更新を重ねていました。
また、広報の仕事をClaude CodeとGitHubに移管してみることを試してみたものの、全てが移管できたわけではありません。ここは人がやったほうがいい、ここは別のツールのほうが早い、というのが試すうちに見えてきました。
たとえばプレスリリースの場合、調査やヒアリング、構成を固めるところまではClaude CodeとGitHubで進めます。集めた材料と骨子を置いて、そこで考えます。原稿を書く段階では、Googleドキュメントに移ります。関係者に見てもらいコメントや修正提案をもらうのは、こちらのほうがやりやすいからです。そして最後、コーポレートサイトへの入稿と社内Slackへのおしらせは、またClaude Codeに戻ります。下書きの形まで用意してもらって、公開のボタンは人が押す。行ったり来たりしているように見えますが、いまのところこの分担がいちばんしっくりきています。
逆に、既存のツールから卒業できたものもあります。定期的に配信しているPodcastの数値の更新は、配信先が複数あるので、毎週それぞれの管理画面からCSVをダウンロードしてきます。あとは「これを取り込んで」と頼むだけで、集計して、表と画像を並べたページにしてくれます。できたものをSlackで共有すれば、社外のパートナーとも同じ数字を見ながら話せますし、過去のデータはGitHubに蓄積されていくので必要なとき出し入れできる状態です。長いあいだ使ってきた集計用のスプレッドシートは、7月末に卒業しました。
途中で、地図をつくってもらった
こうしてClaude CodeとGitHubの行き来が増えていくと別の問題が出てきました。
自分がいまどこにいるのかがわからなくなるのです。何をどこに置いたのか、何をお願いしていたんだっけ、これはもう自動で動いているのか、それともまだ手作業なのか。ひとつずつは覚えているつもりでも、全体としては見えづらくなっていました。
そこで、数週間作業を重ねたところで、地図をつくってもらいました。どこに何があるのか、どの作業が自動で動いていて、どれが手作業のままで、これから何をやりたいのか。それを一枚にまとめたものです。迷ったらそこに戻れるようになって、ずいぶん楽になりました。最初から完璧な設計図がないぶん、小さく始めて段階的に増やしていく進め方は、途中で必ず全体が見えなくなる。であれば、見えなくなってから地図をつくればいいと気づいた瞬間でした。
1か月ほど続けて少し慣れてきたので、社内の他のチームにもスキルの一部を共有する時間をもらいました。こういった共有の場面でも地図が役に立ちました。博物館をつくるようなイメージで、集めて、整理して、いつでも見せられる状態にしておく。学芸員になったような気持ちで臨むと楽しいかもしれない、と伝えてみました。いまのところ、この説明が自分の実感にいちばん近いです。
Claude CodeとGitHubの導入で変わったこと
何が変わったかと聞かれることがありますが、広い博物館の中を何度も歩いて、やっとどこに何があるかわかったような感覚です。アーカイブされているから、余計なことを考えずに、出したい情報を好きに取り出せる。その安心感がいちばん大きい気がします。もう少し整理してみると、大きく変わったと感じることは5つあります。
1. 書いたものが、必ず相手に届く。 GitHubでは、手元で作業したものを共有の場所に上げる手順が必ず入ります。ファイルをどこかに入れて置きっぱなし、ということがほぼ起きません。チームのもうひとりがやったことは私も見に行くし、お互いが全体を見やすくなりました。
2. 視野が広がって、視座が上がる。 「見なきゃ」と思わなくても、自然と全体を見てしまう仕組みになっています。自分の担当だけでなく、チームの動きも、会社として動いているプロジェクトも同じ場所に並んでいるので、ひとつの作業をしているときも、それが何につながっているのかが目に入ります。目の前のタスクだけを見ていたころより、視野が広がって、視座も少し高くなった気がしています。
3. 判断に集中できる。 これまで無駄に見ていた部分が効率化されたので、決めることに時間を使えます。誰かに伝えるために情報を集めなおす、という作業がほとんどなくなりました。
4. 分析での小さな間違いが減った。 データがきちんと入っていれば、加工はいくらでもできます。
5. 試行錯誤の過程が、そのまま残る。 GitHubには、変更をまとめて「これでいいですか」と出してから反映する手順（プルリクエストと呼ばれます）があります。おかげで、何をどう直したのか、なぜその形にしたのかが全部残ります。うまくいかずに引き返した跡も含めて、社内の誰でもあとから辿れる。完成したものだけが置いてある状態より、こちらのほうが安心だと感じています。
アーカイブを重ねて発信もアップデートしていく
いま考えているのは、この先のことです。プレスリリースの数は、これから増えていくものでもないかもしれない。それよりも、自分たちが記録したいことをきちんと記録し続けることのほうが大事なのではないか。チームでそんな話をしています。
たとえば、各チームのマネージャーに定期的に話を聞いて、いまのクラシコムの状況をGitHubへアーカイブしていく。そうしておけば、必要になったときに記事の形にできます。
こうしてClaude CodeとGitHubで構築した私たちの仕事の進め方について、チームでこんな話をしました。
半年先にはもうこの仕組みでさえなくなってるかもしれない。ただ、こうして蓄積しておけば、これから先の変化にもきっと対応できるはず。
道具は変わっていくものですが、集めたものはきっと手元に残って、次の道具を使ってまた使うことができるのではないか、と小さな希望を持っています。
おわりに
Claude CodeとGitHubの活用を模索し、1か月を経た頃、ちょうど社長室の定例で代表・青木と話す機会がありました。青木と話したのはこんなことです。
広報の役割を「インターナル（社内向け）」と「パブリック（社外向け）」に分ける考え方をやめて、すべてのステークホルダーに向けた一体のコミュニケーション活動として考えてみる。そして活動を「知る（反響を観察して把握する）」と「知らせる（実績やノウハウを発信する）」で考えてみる。
社内向けか社外向けかで分けず、活動を知って、知らせる。
こうして言葉にしてみると、この1か月でやってきたことは、私たちが私たち自身のことを正しく知って知らせるための実験だったのだと思います。発信や効率化を最初のゴールに置くのではなく、まず漏れなくきちんと記録する。Claude CodeとGitHubの活用により安心して「観察して把握すること」に集中することができました。
メディアリレーションだけでなく、広報の大切な仕事のひとつとして、その手前に「自分たちが何者かを、正確に、漏れなく残しておく」という仕事があることに、この1か月で気づきました。
身近にある小さな仕事から、AIを使ってアーカイブをしてみる。その一歩が、めまぐるしく進化するツールや環境のなかでも、ぶれずに広報の歩みを進めるための土台になっていくのかもしれません。
