AI エージェントで議事録作成を自動化｜marutto 内製の自社実践事例
marutto では、社内会議の議事録作成を に任せる運用に切り替えました。会議メモ・事前レジュメ・書き手側の補足の 3 ソースを突き合わせて初稿を自動生成し、書き手は「読んで直す」側に回れる体制です。会議 1 件あたり 30〜60 分（感覚値）かけていた初稿の産出時間が、実質 0 分になった自社実践事例です。今では marutto のメンバーが日常的に活用しており、部署を越えて多くの書き手が日々使っています。
| 業種 | IT コンサルティング／DX 支援（自社事例） |
|---|---|
| 企業規模 | 中小企業 |
| プロジェクト主導 | PM・バックオフィス層／marutto 内製 AI 開発チーム |
| 対象者 | 社内で議事録を書く立場のメンバー（バックオフィス・広報PR・PM・マネージャー層など、部署横断で利用） |
| 対象業務 | 会議後の議事録作成・個人別 ToDo 抽出・社内wiki への共有 |
| 導入サービス | まるっと |
| 取り組み時期 | 2026 年 6 月本格運用開始（試用運用 2026 年 3〜5 月） |
| 主な成果 | 議事録初稿の産出時間 30〜60 分（感覚値）→ 実質 0 分。共有リードタイム「翌日以降」→「即日」に短縮 |
1. 背景と課題：
議事録の「書く時間」ではなく「調整する時間」が本業
marutto は、社内定例・案件 MTG・1on1 と、日々多くの会議を回しています。会議のたびに議事録が必要となり、書き手は会議直後にメモを見返しながら決定事項と ToDo を再構築する時間を確保していました。
1 件あたりの初稿作成時間は、およそ 30〜60 分（感覚値）。書き手は他業務の合間にこの作業をこなす形になっており、思考が細切れになりがちでした。参加者への共有までのリードタイムが翌日以降にずれ込むこともあり、会議終了直後の「早く残さなければ」という圧が業務全体の集中を削ぐ構造になっていました。
議事録作成 AI エージェントは、使う人を少しずつ広げてきました。
2026 年 3〜5 月にかけて社内の一部で試用運用を回し、初稿の質・共有リードタイム・機密音声の扱いなど、実運用で確かめるべき論点を検証しました。手応えが得られたため 6 月に社内公開へ切り替え、以降は広報PR・・PM・マネージャーなど、部署を越えたメンバーが日々の議事録業務で使う状態になっています。
対象となった書き手の業務負荷
対象となったのは、社内で議事録を書く立場にあるメンバー（PM・バックオフィス・マネージャー）です。抱えていた業務負荷は次の 3 点に整理できます。
- ● 初稿の産出コスト
- 会議メモから決定事項と ToDo を再構築し、読める形の文章に起こす作業が毎回発生
- ● 個人別 ToDo の整理
- 担当・期限・背景を割り当て直す作業を手で行っており、抜け漏れも起きやすかった
- ● 共有リードタイムのばらつき
- 他業務との兼ね合いで議事録の完成が翌日以降にずれることがあり、「あの件どうなった」の追跡工数が発生
書き手にとって議事録は「作らなければならない」タスクである一方、書くこと自体には価値が置きにくい業務です。読む価値のあるものにするための「調整」の時間こそが本業だ、というのが書き手側の実感でした。ここを起点に、初稿を人が書かない体制を作ることが着手方針になりました。
2. 取り組み：
議事録作成 AI エージェントによる 3 ソース突き合わせと、／ローカル AI の使い分け
marutto は、まるっと
● 議事録作成 AI エージェントの役割
議事録作成において、AI エージェントは以下の一連の流れを担当します。
- ・会議前準備
- 社内wiki 上の該当レジュメを検索・特定し、関連する事前やりとりドキュメントを読み込んで論点を予測
- ↓
- ・会議中
- Web 会議サービスの自動議事録機能（ ベースの文字起こし）で音声を自動テキスト化
- ↓
- ・会議後の突き合わせ
- 3 ソースを統合して初稿を生成（後述）
- ↓
- ・ToDo 抽出
- 担当者ごとにグルーピングし、期限・背景を明示
- ↓
- ・投稿整形
- 社内wiki の標準スタイル（絵文字タイトル・バッジ・アラートブロック・誤変換候補のコラプス）に整形し、指定パス配下に投稿
● 3 ソース突き合わせが初稿の質を決める
議事録の初稿を作る際に AI エージェントが統合するソースは、次の 3 つです。
- 1. 会議メモ
- Web 会議サービスの自動議事録機能で生成された文字起こし
- 2. 事前レジュメ・関連ドキュメント
- 社内wiki 上に置かれた事前資料
- 3. 書き手側の補足情報
- 名前置換ルール（社内呼称・敬称）や書き手固有の補足
● クラウド／ローカル AI の使い分けが機密対応の鍵
marutto がこの取り組みでこだわったのは、クラウド AI とローカル AI を目的別に使い分けている点です。
- 通常運用
- 法人プランの Web 会議サービスの自動議事録機能でクラウド側の LLM を活用し、 エージェント基盤で議事録に整形
- 機密・音声のみの代替経路
- 客先が該当 Web 会議サービスを使わない場合や、機密音声を外部クラウドに出したくない場合は、手元の PC（ローカルマシン）上で OSS 音声認識モデル（whisper 系・ローカル実行）を動かして文字起こしし、そのテキストから議事録を生成
音声データを外部クラウドに出さないローカル経路を併走させることで、データ取り扱い上の懸念を回避しています。利用規約チェックも問題なしと確認済みです。
● 体制
- ・活用オーナー
- 書き手層（PM・バックオフィス・マネージャー等）
- ・作り手
- marutto 内製 AI 開発チーム
- ・利用形態
- 社内利用（お客様の機密情報・音声を外部サービスに出さない設計）
体制図
体制図：3 ソース／クラウド AI・ローカル AI 使い分けの関係矢→AI エージェント（社内呼称：秘書エージェント）→書き手
3. 効果：書き手の Before / After
導入前後で、書き手が議事録に費やす時間と会議後の状態が変わりました。
| 対象 | Before | After |
|---|---|---|
| 初稿の産出時間 | 1 件あたり 30〜60 分（感覚値・書き手が手で再構築） | 実質 0 分（AI エージェントが自動生成） |
| 書き手のスタンス | ゼロから書く | 出来上がった初稿を読んで直す |
| 個人別 ToDo の割り当て | 会議後に手作業で振り分け | 担当・期限・背景付きで自動抽出 |
| 共有リードタイム | 翌日以降にずれ込むことがあった | 会議終了から即日で共有 |
| 機密音声の会議 | 対応方針が個別判断 | ローカル経路の 2 段連鎖で対応可能 |
エピソード 1：会議直後の「早く残さなきゃ」の圧が消えた
会議終了後、書き手が真っ先に議事録に取りかかる必要がなくなりました。AI エージェントが自動で初稿を組み上げ、 上に整形済みで投稿するため、書き手は「読んで直す」フェーズから入れます。他業務との頭の切り替えコストが下がり、会議直後に別作業へ集中できる時間が生まれました。
エピソード 2：個人別 ToDo で「あの件どうなった」の追跡工数が減った
AI エージェントが会議中の発言から ToDo を抽出し、担当者ごとにグルーピングして期限・背景付きで書き出します。この形式が社内で定着したことで、参加者は自分の担当分を会議直後に把握でき、「あの件どうなった」の追跡やリマインドの工数が明確に減りました。
エピソード 3：機密音声もローカル経路で対応可能になった
客先の音声を外部クラウドに出さない前提の会議でも、ローカル環境の OSS 音声認識モデルで文字起こしし、そこから議事録を生成する 2 段連鎖で対応できるようになりました。従来は個別に判断していた機密音声の議事録対応が、あらかじめ設計された代替経路として運用に組み込まれています。
4. 議事録作成 AI エージェントを日常運用する書き手の視点から見た変化と学び
書き手層は、議事録作成 AI エージェントを社内の会議運用に組み込んで日常的に使う立場から、この取り組みを主導しました。運用を通じて marutto が得た手応えは、「議事録は書く時間よりも、そもそも人が書かなくてよい形にする設計が本質だった」というものです。
会議直後の圧が消え、初稿を読んで直す立場に立てるようになったことで、書き手の集中の質が変わりました。個人別 ToDo が定着し、参加者間の追跡もスムーズになっています。運用を続けるなかで書き手が得た気づきは、次の 4 点に集約されます。
1. 議事録は「書く時間」より「調整する時間」が本業
議事録づくりで価値が置かれるのは、書き起こす作業ではなく、「決定事項として何を残すか」「誰の ToDo として書くか」を読める形に調整する部分です。AI エージェントに初稿づくりを任せたことで、書き手が調整に使える時間の比率が上がりました。議事録の本業は「書く」ではなく「読める形に調整する」ことである、という切り分けが時短の実体になります。t
2. 3 ソース突き合わせで、初稿の質は決まる
音声起こしだけを AI に渡しても、初稿は「読んで直せる状態」まで届きません。会議メモ・事前レジュメ・書き手側の補足を 3 ソースとして統合することで、議論の骨子に沿った初稿が上がってくる状態を作りました。初稿の質を決めるのは、AI の性能ではなく、渡す情報の合わせ方である、というのが運用を通じて見えた設計原則です。
3. クラウド AI とローカル AI の使い分けが、機密対応の鍵になる
会議によっては、音声を外部クラウドに出せない前提のものがあります。この場面で「対応不可」にせず、ローカル環境で OSS 音声認識モデルを動かす代替経路を最初から設計に組み込んだことで、機密対応と自動化を両立できるようになりました。クラウド AI とローカル AI を目的別に使い分ける設計が、社内での AI 活用の適用範囲を広げる鍵になります。
4. 個人別 ToDo で、会議の「あと」が組織の資産になる
議事録を書き手一人の作業として閉じるのではなく、担当者ごとに ToDo を切り出して参加者に配布する形が定着したことで、会議の成果が組織の資産として残るようになりました。「あの件どうなった」の追跡工数が減り、会議のあとに発生していた小さな確認コストがまとめて消えています。議事録は書き手のためのメモではなく、参加者全員の ToDo リストとして機能させると、会議の生産性そのものが上がります。
5. よくある質問
Q1. 議事録作成 AI エージェントとはどのようなツールですか？
marutto が自社で構築・運用している社内向けの AI エージェントで、会議前後の運用を丸ごと担います（社内呼称：秘書エージェント）。会議前は社内wiki 上のレジュメを検索・読み込みし、会議中は自動議事録機能で文字起こしを取得。会議後は 3 ソース（会議メモ／事前レジュメ／書き手側の補足）を突き合わせて議事録の初稿を生成し、個人別 ToDo を抽出したうえで、社内wiki の標準スタイルに整形して指定パスに投稿します。
Q2. なぜ議事録作成時間が実質 0 分になったのですか？
書き手が初稿を書くのではなく、AI エージェントが 3 ソース突き合わせで自動生成した初稿を「読んで直す」運用に切り替えたためです。従来は 1 件あたり 30〜60 分（感覚値）かけて会議メモから決定事項と ToDo を再構築していましたが、この工程を AI エージェントに任せることで、書き手が初稿づくりに費やす時間が実質 0 分になりました。ここでの計測対象は「初稿の産出時間」であり、「読んで直す時間」は含みません。
Q3. 3 ソース突き合わせのメリットは何ですか？
初稿の質が「読んで直せる状態」まで上がる点です。音声起こしだけでは議論の骨子が拾えず、事前レジュメがなければ論点の重み付けができません。書き手側の補足がなければ、固有名詞や社内呼称の精度が担保できません。3 つのソースを統合することで、それぞれの弱点を補い合い、初稿の完成度が実用レベルに乗ります。
Q4. 音声のみが残る会議や、機密音声にはどう対応していますか？
手元の PC（ローカルマシン）上で OSS 音声認識モデル（whisper 系・ローカル実行）を動かして文字起こしし、そのテキストから議事録を生成する 2 段連鎖の代替経路を設計しています。音声データを外部クラウドに送出しないため、機密音声の会議や、客先が対応 Web 会議サービスを使わない場合にも運用可能です。
Q5. どのような立場の人に向いていますか？
社内定例・案件 MTG・1on1 と、日常的に多くの会議を回している PM・バックオフィス責任者・マネージャー層に向いています。特に「議事録を書く時間が他業務を圧迫している」「会議直後の集中を別業務に振りたい」「会議後のリードタイムを短くしたい」といった課題を抱える立場に効果が出やすい構成です。
Q6. 誤変換や、事前レジュメがない突発会議にはどう対応していますか？
自動議事録機能は、クラウド・ローカルとも同音異義語・固有名詞で誤変換することがあり、書き手側の補足で名前置換ルールを渡すことで精度を担保しています。事前レジュメが用意できない突発 MTG では 3 ソースのうち 1 つが欠けるため、初稿の精度がやや落ちる場合があり、書き手が読んで直す工程で吸収する運用としています。個人別 ToDo の期限が会議中に言明されなかった場合は「期限：未定」で残し、後追いで人が確定させます。
Q7. この議事録作成 AI エージェントは外販していますか？
現時点では marutto の社内利用に留めています。まるっと