Claude Code秘書に高品質な議事録・発表まとめを作らせる方法

morimorihoge です。
今年も弊社BPSでは夏の記事執筆イベントとして、8月いっぱいは毎日弊社や弊社にゆかりのあるメンバーの記事を投稿していきます。
まずはトップバッターということで僕から。先日Claude Codeに秘書をやらせるという記事を書きましたが、今回はこの続きになります。

• 参考: Claude Code秘書で実現するマルチプロジェクト業務整理: 1ヶ月使い倒して得た運用ノウハウと成果

議事録作成の重要性

例のアレで世の中でリモートワークが一般化したり、世の中的な働き方改革の流れで時短勤務やフレックスタイムなどで働く時間・場所の多様化が進んでいます。
これまでは顧客打ち合わせなどある程度重要度の高い会議だけで議事録を作成していましたが、非同期で働くメンバーが増えたことで意思決定の過程や履歴を後から参照・検索可能にしておきたいというニーズも強まりました。

開発者間でも「ちょっとテキストチャットで説明するのめんどいからZoom/Meetで繋いで相談しましょう」とかがあると思いますが、こういったAd-hocな会議というか相談のようなものをいちいち議事録を手で取るのは大変です。
会話した当事者同士はそれで納得するので良いのですが、後々他のメンバーからは追いかけられないため、結論だけが共有されているとコードレビューなどで「ここはなぜこういう意図の設計にしたの？」などという質問が出てきて、そこを説明しようと思ったら詳細を思い出せない・・・なんてこともあるあるです。

AI議事録のかゆいところに手が届かないところ

既に世の中のリモート会議サービスの多くが文字起こし・議事録作成機能を備えています。MeetはGemini、Zoom、国内でもAIGIJIROKU なんてサービスもありますよね 😇
こういったAI議事録サービス、いいじゃん！と一見思うかもしれませんが、実際に使ってみると色々な課題があることに気付きます（と言ってもMeet / Zoomくらいしか試していませんが）。

• 議事録の中で使われる固有名詞（プロジェクト名や人の名前、ツール名など）が正しく認識されない
• 作成された議事録の内容が議事録の中に閉じており、別途プロジェクト管理しているGitHubやJiraのIssueなどに適切に紐付けがされていない

最近のAIの進化のおかげでぱっと見の品質はかなり上がってきているのですが、やっぱりまだ人間がきちんと整理した議事録に比べるとかなり見劣りする印象です。
特に、プロジェクト管理ツールとの連携がきちんとされていないのは地味に見にくいポイントです。
議事録を読む側としても、当該話題からプロジェクト管理ツールのIssueにリンクされていると使いやすいのですが、そういったことはなかなか難しいです。

結果として、AIで取った議事録についてはきちんとお客様と共有するようなものについては人間が整形しなおして情報を修正したり、内部MTGのAI議事録はとりあえず取って保存するけどあまり利用することはなくなってしまったりすることが多いなと感じます。

Claude Code秘書に議事録を書かせる

Claude Code秘書の大きな特徴は、単なる文字起こしではなく、プロジェクトの背景情報を踏まえた構造化された議事録を作成できることです。前回の記事で紹介したように、プロジェクト固有の情報をファイル化して管理しているため、議事録作成時にそれらの情報を参照して補完してくれます。また、AgentがMCPサーバーや各種コマンドを通じてAPIを叩くことで、プロジェクト管理ツールの情報も能動的に取得できます。

基本的な使い方

最もシンプルな使い方は、Google MeetやZoomの文字起こし結果をClaude Code秘書に渡すことです：

PROJプロジェクトの週次定例MTGを実施しました。文字起こしを添付するので議事録を作成してください。

[Google Meetの文字起こしURLや、Zoom文字起こしの生テキストを貼り付け]

すると、以下のような構造化された議事録を自動生成してくれます：
※実際の過去の議事録をベースに内容をダミー化しています

# PROJ 週次定例MTG 議事録 (2025-07-31)

## 開催情報
- **日時**: 2025年7月31日（木）14:00-14:30
- **参加者**: 
  - 森雅智（Masato Mori）- プロジェクトリーダー
  - 田中（h-tanaka）- フロントエンドエンジニア
  - 山田（s-yamada）- バックエンドエンジニア  
  - 鈴木（QA担当）- QAエンジニア
- **会議形式**: オンライン

## 進捗報告

### UI改修対応（PR#745）
- **担当**: @morimorihoge
- **状況**: クライアントから追加フィードバック受領
- **関連**: [PR#745 ユーザー管理画面の改修](https://github.com/company/proj/pull/745)
- **関連Issue**: [PROJ-456 管理画面のユーザビリティ改善](https://company.backlog.jp/view/PROJ-456)
- **対応内容**: ボタン配置とフォームバリデーションの調整
- **完了予定**: 今週金曜日

### テスト環境検証
- **担当**: @h-tanaka  
- **状況**: 動作確認完了・問題なし
- **対象機能**: 新規ユーザー登録フロー、管理機能改修
- **次のステップ**: ステージング環境への反映準備

### バックエンドパフォーマンス改善
- **担当**: @s-yamada
- **進捗**: データベースクエリ最適化実装中
- **関連**: [PROJ-789 検索処理高速化](https://company.backlog.jp/view/PROJ-789)
- **効果**: レスポンス時間30%短縮見込み
- **完了予定**: 今週中

### 8月リリース準備
- **担当**: @suzuki-qa
- **状況**: QA計画策定完了
- **テスト期間**: 8月第2週（8/12-8/16）
- **リリース予定**: 8月第3週（8/19-8/23）
- **テスト対象**: UI改修、パフォーマンス改善、セキュリティ強化

## アクションアイテム

| 担当者 | タスク | 期限 | 優先度 |
|--------|--------|------|--------|
| 森 | PR#745のフィードバック対応完了 | ~8/2（金） | 🔥高 |
| 森 | クライアントへの修正内容報告 | ~8/5（月） | ⚡中 |
| 田中 | ステージング環境への反映作業 | ~8/6（火） | ⚡中 |
| 山田 | パフォーマンス改善の実装完了 | ~8/1（木） | 🔥高 |
| 鈴木 | QAテストケースの詳細化 | ~8/9（金） | 📝通常 |

## 決定事項
- UI改修のフィードバック対応を最優先で実施
- パフォーマンス改善は今週中に必ず完了
- 8月リリースのQA期間は8/12-8/16で確定
- 次回MTGでリリース判定会議を実施

## 懸念事項・リスク
- クライアントからの追加フィードバックによるスケジュール遅延
- パフォーマンス改善でのデグレード発生可能性
- 8月第3週リリース時の他プロジェクトとの競合

## 次回MTG予定
- **日時**: 2025年8月7日（木）14:00-14:30
- **主要議題**: 
  - フィードバック対応結果確認
  - パフォーマンス改善効果測定
  - 8月リリース最終判定

Claude Code秘書議事録の優れた点

1. プロジェクト情報との自動連携

最も大きな特徴は、議事録作成時に関連するGitHub Issues/PRs、Backlog課題、Google Docsなどへのリンクを自動で挿入してくれることです。

例えば、会話の中で単に「PR123」と言及されただけでも：
- そのPRの正確なタイトルを取得
- 関連するIssueとの紐付けを確認
- 適切なURLリンクを生成
- 現在のステータス（レビュー中、マージ済みなど）も含めて記載

これにより、議事録を読む人が後から詳細情報にすぐアクセスできるようになります。

2. 文脈に応じた構造化

Claude Code秘書は会議の性質に応じて適切な構造で議事録を作成します：

定例MTGの場合:
- プロジェクト別進捗報告
- アクションアイテム
- 決定事項
- 次回予定

技術検討会議の場合:
- 検討議題
- 技術選択肢の比較
- 決定した技術・理由
- 実装方針
- TODO/次のステップ

顧客打ち合わせの場合:
- 出席者（社内・顧客）
- 顧客からの要望・フィードバック
- 回答・提案内容
- 今後の対応方針
- フォローアップ予定

3. 固有名詞の適切な認識・補完

プロジェクト固有の情報ファイルを参照することで：

• 人名: 漢字間違いなどのない正確な記載（projects設定の方にメンバーリストが明記してある）
• プロジェクト名: 正式名称での統一
• ツール名・サービス名: 表記ゆれの統一
• 専門用語: プロジェクト内での統一された用語に変換

例えば、会話で「あのマイグレの件」と言われても「データベース移行プロジェクト」として正確に記録されます。
当該タスクのIssueなどもあるなら参考リンクも自動で挿入されます。
※たまに細かく付けてくれないこともありますが、その際はその旨を指摘して更新・作り直しさせれば良い

4. 優先度・緊急度の自動判定

会話の内容から自動的に優先度を判定し、アクションアイテムに反映：

• 🔥 緊急: 本番障害、期限当日のタスク
• ⚡ 高優先: 他者待機中のレビュー、1週間以内の期限
• 📝 通常: 定常業務、長期タスク

この判定により、議事録を見ただけで何を優先的に対応すべきかが一目で分かります。

・・・とはいえ、これは正直イマイチうまく認識してくれないことも多いです。このあたりはまだ人間がチェックした方が適切な内容になるかと思います。

実際の運用フロー

• 1. 事前準備: プロジェクト情報ファイルの最新化
  • これは普段からClaude Code秘書を使っていれば特に何かを議事録作成向けにやる必要はありません
• 1. 会議実施: Google Meet/Zoom等で文字起こし有効化
  • これを忘れるとどうしようもないので注意。ZoomはMeeting自体に文字起こしOn/Offの設定があるので、事前に確認しておく
• 1. 議事録生成: 文字起こし結果をClaude Code秘書に投入
• 1. レビュー・修正: 生成された議事録の内容確認・微調整
• 1. 共有: 関連チャンネルやプロジェクト管理ツールに投稿

この流れで、従来は会議中に一生懸命メモした上で会議後に整理し直しなどをしていた手間が0になりました。

Claude Code秘書議事録の限界

一方で、Claude Code秘書による議事録作成にも限界があります。運用して分かった主な制限事項を紹介します。

1. 文字起こし品質への依存

Claude Code秘書の議事録品質は、元となる文字起こしの精度に大きく依存します。
業界特有の用語、略語の多用があると怪しい内容になってしまうことも多いですが、固有名詞についてはprojectsファイルに記載したり、GitHub等でも積極的にその用語を使うことで認識精度を上げることができます

なお、Zoom文字起こしは結構日本語の認識が怪しいことも多いですが、割と怪しい状態の文字起こしを食わしてもなんとかなります。

• 移民。ュータブルデータモデル （注: Immutable Data Model）
• レイズアップグレード （注: Rails Upgrade）

とかがちらほら混じってますが、まとめさせたもの自体はおかしなことを言っていませんでした。賢い。

2. リアルタイム性の限界

Claude Code秘書は事後的な議事録作成のため、会議中のリアルタイムな情報整理はできません：

• 会議中の意思決定をその場で記録・共有
• ホワイトボードや画面共有の内容統合
• 会議中の追加資料・URLの即座な整理

このような用途には従来通り人間による記録が必要です。
なお、Google Docs等を使って画面共有しながら議事録を人力で書いたりするのであれば、その議事録データも文字起こしの際に食わせてやった上で「議事録に記載されていない内容を中心にまとめて」といったプロンプトを投げることで、書き起こしし損ねた情報を拾い上げることもできます。

3. 複雑・プロジェクト固有な議論の理解限界

非常に専門的で複雑な技術議論や、ハイコンテクストでprojectsにも背景が記述されていないような内容については、Claude Code秘書でも完全に理解できない場合があります：

• 参加メンバーの中で言葉を省略しても通じ合っているような会話
• 特殊なビジネス用語や社内用語などが多用されている会話

このような会議では、議事録のベースをClaude Code秘書に作らせて、詳細部分は人間が補完する必要はありそうです。

4. コストと利用制限

前回の記事でも触れましたが、頻繁な議事録作成にはMAX 20xプラン (200USD/月) が現実的です：

• 1日2-3回の会議で議事録作成: 月10-15M tokens程度消費
• 文字起こしが長いほどtoken消費量が増加

社内勉強会でも使ってみる

同じことを毎週やっている社内勉強会でもやってみました。
社内勉強会では発表スライドを準備して話しているのですが、僕の場合スライドはあくまで話す内容のメインルートとしては用意しつつ、実際にはスライドに書いていないことも沢山雑談的に話すことが多いです。

そんなとき、議事録の際と同様に発表資料と文字起こしを渡しつつ「発表資料に記載していない内容を中心に整理して」といった形でまとめさせてみます。

すると、以下のような感じで雑談的に話していた内容を良い感じに整理してくれます。

## スライドにない発表時の重要なコメント・補足説明

### 1. アーキテクチャ設計の実践的な話

#### 式年遷宮の考え方
- 10年前のアーキテクチャは現代では老朽化している
  - 10年前だとフロントエンド技術が現在とは全く違う
  - ライブラリもアップデートされなくなる
- インクリメンタルなアップデートよりも、全面的な作り直しが必要な場合がある
- 「式年遷宮」として原語・アーキテクチャレベルから作り直すことが実際に多い
- 老朽化したシステムのメンテナンスを続けるより、どこかで式年遷宮が必要

#### YAGNIの重要性
- 「You Ain't Gonna Need It」の略
- アーキテクチャのリファクタリングが難しいからといって、必要がない時から複雑なアーキテクチャにする必要はない
- 最初の設計が将来にわたって最適である可能性は低い
- システムが本当に使われて価値あるものになるかも含めて「博打感」がある

### 2. 技術的な歴史と背景

#### CI/TDDの歴史
- 2000年当時、CIといえばHudson（Jenkinsの前身）の時代
- JavaコミュニティではTDD（テスト駆動開発）の概念は古くからあった
- JUnitが世界でエンタープライズアプリケーションで使われた最初のユニットテストフレームワーク（おそらく）
- RailsのテストやRubyのTest::Unitの元祖
...略

また、スライドに書いてなくて雑談的に話した内容は真偽がうろ覚えだったりすることも往々にしてあるので「この整理した内容の各項目について、技術的・歴史的な正確性の観点で誤りがないか確認し、問題があれば正しい解釈を説明して」といったプロンプトを投げると、

## 正確な記述の確認

### 1. CI/TDDの歴史（セクション2）
- **Hudson → Jenkins**: ✅ 正確
  - 2011年にOracleとの商標問題でフォーク
  - 歴史的事実として正しい

- **JUnitが最初のユニットテストフレームワーク**: ⚠️ 若干の注意が必要
  - JUnit（1997年）は確かに先駆的で、エンタープライズJavaでの普及に大きく貢献
  - ただし、SmalltalkのSUnit（1994年）がJUnitの元になっている
  - 「エンタープライズアプリケーションで広く使われた最初」という表現なら正確

### 2. 式年遷宮の考え方（セクション1）
- **10年でのアーキテクチャ老朽化**: ✅ 妥当な見解
  - 技術の進化速度を考慮すると現実的な期間
- **フロントエンド技術の変化**: ✅ 正確
  - 特に2010年代の変化は激しい（jQuery → SPA → React/Vue/Angular）

### 3. ActiveRecordパターンの限界（セクション4）
- **20-30程度のモデルまでが適切**: ✅ Martin Fowlerの見解と一致
- **モジュラーモノリス**: ✅ 2020年代に入って注目される概念として正確
  - マイクロサービスの複雑さへの反動として登場
...略

みたいな感じで内容に対しての正確性チェックもやってくれます（これで嘘をつかれたらまあ仕方ない）。

社内でシニアエンジニア同士が雑談しているような内容にはかなり技術的に面白い内容が多いのですが、内容についていけないと？？？なまま情報が流れてしまいます。
しかし、こうした文字起こしからのまとめにもClaude Code秘書を使うことで後から追いかけて確認できる形式にできます。
新人教育にも使えそうな気配ですね。よさげ。

ただ、実際に何度か使ってみると、雑談的な話題については「この人こんなこと確証的に言ってなかったけどな？」といったことが書かれたりもして、内容の細かい正確性にはまだまだ限界がありそうです。

これは、仕事の会議では合意形成を目的とするので、曖昧な物言いよりは具体的に「これでクローズします」「これはこう決めましょう」といった話の進め方をしますが、勉強会の雑談sectionなどでは「こういうのもあって、こういう話らしいよ？」「こういうことを言っている人もいる・・・らしい。」みたいな曖昧な話題も持ち出すことがあるからだとは思います。
社内用の雑多なログなら良いですが、エビデンスとして何かに使いたいような用途では気をつけた方がよいでしょう。

まとめ

Claude Code秘書による議事録作成は、従来のAI議事録ツールの「かゆいところに手が届かない」問題を大幅に改善してくれます。
また、これまではその打ち合わせに参加しないと得られなかった情報についても良い感じに整理してくれるので、打ち合わせに参加できなかった時の置いて行かれ度合いを下げることにも繋がるでしょう。

まだまだ改善の余地もあるClaude Code秘書ですが、今後も改善を続けつつ、良さそうなネタがあればまた紹介したいと思います。ではでは

---