会議が終わった瞬間、宿題が動き出す仕組みの作り方

会議そのものより、会議が終わったあとのほうが大変だ——。決まったはずのことが実行に移らない、議事録を作るだけで時間が過ぎる、担当と期限が曖昧なまま次の会議が来る。この「会議後の目詰まり」は、多くのチームに共通する悩みです。

いま、この目詰まりは仕組みで解けます。しかも、必要なのは会議の録音を書き起こした議事録テキストひとつだけ。鍵になるのは「スキル」です。スキルとは、AIに渡す作業手順書のこと。「議事録はこう整える」「調査はこう進める」といったやり方を文章でまとめた部品で、Claude というAIでは Agent Skills という名前で提供されています。役割の異なるスキルを複数用意し、指揮者がオーケストラをまとめるように束ねて順に動かす——これを「オーケストレーション」と呼びます——と、会議が終わると同時に後続タスクが分類・実行され、結果まで出てきます。人が担うのは、各ステップの承認とひとことのフィードバックだけ。本記事では、その設計図と作り方を、当社の運用知見を交えて具体的に整理します。

目指す姿 ― 文字起こしを渡すだけで、後続タスクが動き出す

理想は、会議の議事録を渡した瞬間から、後続タスクが自動で片づき始めている状態です。

会議が終わって席に戻る頃には、文字起こしから起こされたタスクが並び、実行に向くものは処理が済んで結果が届いている。担当者は要所で内容を確認し、承認するだけ。ここで大切なのは、この一連を動かすために特別な基盤や複雑なツール連携を用意していない、という点です。入力は文字起こし、処理はスキルの連携、判断は人——このシンプルさが、導入のハードルを大きく下げます。

渡すのは、文字起こしひとつ。あとはスキルの連携が後続を回します。

発想の転換 ― 道具を「つなぐ」より、手順書を「束ねる」

この仕組みの肝は、ツール同士をつなぎ込む開発ではなく、役割の異なる手順書＝スキルを束ねて動かすことにあります。

これまでの業務自動化は、議事録ツール・タスク管理・チャットといった業務ツール——いわゆる SaaS（サース。ブラウザから使う月額制の業務サービスのことです）——同士を、API や webhook と呼ばれる仕組みでつなぎ込む形が主流でした。API はシステム同士がデータをやり取りするための接続口、webhook は「あるツールで起きた出来事を、別のツールへ自動で知らせる」仕組みです。いわば、道具と道具を専用の配線でつないでいく発想で、柔軟ではありますが、配線と保守の負担が重く、作り込みが増えるほど壊れやすくもなります。

ここでの発想は違います。「やり方」を手順としてまとめた再利用可能な部品＝スキルを役割ごとに用意し、全体の段取りを差配する指揮役のAI——本記事では「オーケストレーター」と呼びます——が、それらを順に、あるいは並行に呼び出す。道具と道具を配線でつなぐのではなく、レシピを何枚か用意して、料理長が段取りよく指示を出していくイメージです。スキルという単位については、別記事のAIに意図を正しく伝える設定作法で詳しく扱っています。

配線ではなくスキルの組み合わせで考えると、入り口は文字起こしひとつに絞られ、後続は部品の連携として素直に設計できます。ツールを増やすたびに接続を作り込む発想から、必要な「やり方」をスキルとして足していく発想へ——この転換が、仕組みを軽く、壊れにくくします。

この違いは、運用が始まってから効いてきます。ツールを配線でつなぐ方式は、どこかのツールの仕様が変わるたびに接続が壊れ、その都度メンテナンスが要ります。連携する先が増えるほど、壊れる箇所も増える。一方、スキルを組み合わせる方式なら、直したいときに直すのは「やり方を書いた手順」であって、システム同士の接続ではありません。手順は普通の日本語の文章で書かれているので、担当がエンジニアでなくても読めて、直せる。作り込みが軽い分、始めるハードルも、続けるコストも下がります。

会議を分類し、後続タスクを推察する

最初のスキルが、文字起こしを読んで会議を分類し、そこから必要な後続タスクを推察します。

このスキルは、まず議事録を正規化——話し言葉のゆらぎや表記のばらつきを整え、決まった形にそろえること——したうえで、会議の種別・要約・決定事項・宿題・ネクストアクション（次に取るべき行動）の項目に整理します。会議の種類によって得るべき成果物は変わるため、まず「どんな会議だったか」を見分けることが、後続の精度を左右します。

この段の最後で、人が議事録に目を通し、必要なら補正します。ここで一度整えておくことが、後続すべての土台になります。分類の精度が上がれば、後続タスクの推察も的を射たものになり、無駄な処理が減っていきます。

会議を分類することには、もうひとつの意味があります。同じ「議事録」でも、意思決定の会議で欲しいのは決定の記録と根拠であり、ブレストで欲しいのは論点の整理と次に検証すべき仮説です。ここを取り違えると、せっかく自動で後続を回しても「欲しかったものと違う」成果物が並ぶことになります。だからこそ、最初に「これは何の会議で、何を得たいのか」を見極める。人がこの一点だけ最初に確認しておけば、後続の精度は大きく変わります。分類は、単なる仕分けではなく、後続すべての方向づけなのです。

後続タスクを要件定義し、担い手を仕分ける

議事録が固まったら、指揮役のオーケストレーターが後続タスクの要件——何を、どこまで、どんな形でやるか——を定め、種別ごとに実行スキルへ振り分けます。

ここが設計の要です。文字起こしや要約、タスク抽出、一次的な数値確認や調査はスキルが速く正確にこなせます。一方で、優先順位づけや最終的な実行可否は、事業の文脈を持つ人が握るべき領域です。

実装の観点では、この仕分けを「ルールで機械的に絞り込む → スキルが判定する → 人が承認する」という3層にすると素直に組めます。1層目は、あらかじめ決めたルールだけで行う絞り込みです。たとえば「支払い・契約に関わるものは自動化の対象から外す」のように、誰がいつ実行しても必ず同じ結果になる処理（こうした性質を「決定論的」と呼びます）で、明らかに自動化になじまないものを最初に除外します。残りをスキルが実行可否や種別つきで候補に絞り、最後に人が承認する。無駄な処理と誤りを前段で機械的に落とすのがコツです。1回の会議から出るタスクは多いので、判定にかける件数に上限を設けておくと、コストも誤りも抑えられます。

スキルを並行で動かし、成果物まで出す

振り分けられたタスクは、種別ごとの実行スキルが並行して処理し、成果物としてまとめます。

たとえば、調査が要るものは調査のスキル、資料化が要るものは文書作成のスキル、数値の確認は分析のスキルが担当します。互いに独立したタスクは同時に走るので、待ち時間が短くなります。最後に、生成された成果物が元の議事録の文脈・決定事項に沿っているかを検証するスキルを通し、ずれがあれば該当のタスクだけをやり直します。全体像は次の流れです。

各段をゆるやかにつないでおくと、途中に人の承認を差し込んだり、一部だけ作り直したりが容易になります。

実行スキルの中身 ― 役割は1つに絞り、AIは賢さで使い分ける

並行して走る実行スキルは、それぞれ役割を1つに絞って設計します。

たとえば、数値確認のスキルは「指定された指標を集計し、要点だけを短くまとめる」ことに徹し、要因分析のスキルは「なぜその数字になったのかの仮説を、根拠とともに示す」ことに徹します。役割を混ぜないことで、いつどのスキルを呼ぶかが明確になり、出力の品質も安定します。

コストと品質を両立させる勘所は、タスクの重さに応じて「AIモデル」を使い分けることです。モデルとは、AIの頭脳にあたるエンジンのこと。ChatGPT や Claude のようなAIサービスの中にも、速くて安価な軽量のモデルと、深く考えるのが得意なぶん料金も高い上位のモデルという複数の種類があり、切り替えて使えます。分類や実行可否の判定のように速さが要る処理は軽量なモデルに任せ、要因分析のように深い推論が要る処理だけ上位のモデルに回す。すべてを最上位のモデルで処理すると費用がかさむため、「軽い判定は軽く、重い分析は厚く」と役割で振り分けるだけで、無駄を抑えられます。

出力の形も、スキルごとにそろえておきます。「要約」と「詳細」を分けて返す、といった決まった形式で出させると、結果をそのまま次の処理や共有に回せます。何を入力に取り、何を返すかを手順の中で明示しておくことが、部品としての再利用性を高めます。

スキルを増やしていくときのコツは、いきなり多機能な万能スキルを作らないことです。「議事録を整えるスキル」「数値を確認するスキル」「調査するスキル」「共有文を書くスキル」——このくらいの粒度で、一つの役割に絞って用意します。粒度が細かいほど、いつどれを呼ぶかの判断が明確になり、組み合わせの自由度も上がります。ひとつのスキルに機能を詰め込むと、「このスキルはどんなとき使うのか」が曖昧になり、オーケストレーターも人も迷いやすくなる。小さな部品を必要な分だけ組み合わせる——これはソフトウェアづくりの発想とも共通しています。

検証と差し戻し ― 品質を保つ仕組み

自動で走らせる以上、出てきた成果物が的外れでないかを確かめる仕組みが要ります。

そこで、実行スキルの後ろに「レビュースキル」を置きます。生成された成果物を、元の議事録の決定事項・文脈と突き合わせ、ずれていないかを検証する役割です。整合していればそのまま次へ、ずれていれば該当のタスクだけを差し戻して作り直します。全体をやり直すのではなく、問題のあった部分だけを戻すのが、無駄を出さないコツです。

検証を別のスキルに担わせるのには理由があります。作った本人（同じスキル）に「これで合っているか」を確認させると、自分の出力を肯定しがちで、見落としが起きます。役割を分け、別の視点で「議事録の決定と食い違っていないか」だけを見る係を置くことで、チェックが機能します。人間の仕事でも、書いた人とは別の人がレビューするのと同じ発想です。差し戻しの条件をあらかじめ決めておけば、どこまでを自動で戻し、どこからを人に上げるかの線引きも明確になります。

この「作る→検証する→ずれたら戻す」という小さなループが、自動化の信頼性を支えます。検証を欠いたまま高速に回す仕組みは、速く間違え続ける装置になりかねません。検証の閉じたループがあってはじめて、安心して任せられる範囲が広がっていきます。

事例 ― ある定例会議を通してみる

ここまでの流れを、ひとつの定例会議に当てはめてみます。特定の案件を指すものではなく、考え方を伝えるための一般化した例です。

たとえば、あるチームの週次定例。会議が終わると、録音の文字起こしをこの仕組みに渡します。最初に議事録化スキルが、これは「定例・進捗の会議だ」と分類し、要約・決定事項・宿題・ネクストアクションに整理します。担当者はこの議事録にざっと目を通し、ニュアンスがずれている箇所だけ直す。ここまでで数分です。

次に、オーケストレーターが後続タスクを洗い出します。「先週施策の数値を確認する」「競合の動きを一次調査する」「決定事項を関係部署に共有する」——といった具合に、種別ごとに振り分けられます。このうち、数値確認のように定型で安全なものは自動実行に回り、結果が短くまとまってチャットに返ってきます。競合調査のように判断を含むものは、いきなり実行せず「これを調べますか？」という候補として提示されます。

担当者は、届いた候補にボタンで応えるだけです。そのまま進めてよければ承認し、観点を足したければ「価格の切り口も見て」とひとこと添える。実行された成果物は、レビュースキルが議事録の文脈と突き合わせ、ずれていれば該当分だけ戻して作り直します。会議が終わって席に戻る頃には、数値の確認結果が手元にあり、調査は走り始め、共有文の下書きができている。担当者がやったのは、議事録の確認と、いくつかの承認、ひとことの補足だけ。「準備と運搬」から解放され、「何を優先し、どう判断するか」に時間を使えるようになる——これが、この仕組みがもたらす一番の変化です。

人は「承認とフィードバック」だけを担う

この一連で人が担うのは、各段の承認と、必要なときのひとことのフィードバックだけです。

なぜ最後の実行まで自動にしないのか。ある実装事例では、当初はタスクの起票——課題を管理ツールへ1件ずつ登録すること——から実行まで、完全に自動化していました。ところが、AIが「優先度が高い」と選ぶものと、議論を経たチームが「いま動かしてほしい」と思うものが、しばしば噛み合わなかったのです。文字起こしのテキストには、議論の温度感が載らないから。そこで最終的な取捨を人に戻したところ、精度も納得感も安定しました。

当社でも、会議の文字起こしを起点に、議事録化から後続タスクの要件定義・実行・レビューまでをスキルの連携で回しています。運用の中でたどり着いたのも同じ結論でした。下ごしらえと運搬はスキルに任せ、「何を実行するか」の最終判断は人が握る。この線引きにすると、速さと納得感が両立し、暴走も防げます。

フィードバックの余地も残します。「このまま進める」だけでなく「補足して進める」という選択肢を用意しておけば、人がひとこと意図を添えて軌道修正できます。承認とフィードバックという軽い関与が、自動化の安全弁になります。全部を任せるのでも、全部を自分でやるのでもない。この「あいだ」の設計こそが、続く自動化の肝です。

運ぶのはスキル。決めるのは、議論の温度感を知る人です。

なぜ、文字起こしだけで実現できるのか

複雑な連携なしにこれが成り立つのは、スキルが「やり方」を自分の内側に持っているからです。

一つひとつのスキルには、目的・前提・手順・出力の形式が書き込まれています。だからオーケストレーターは、個別のツールを一つずつ配線する必要がなく、「どのスキルを、どの順で呼ぶか」を決めるだけで済みます。入り口が文字起こしひとつに絞れるのも、後続の各処理がスキルの内側で完結するからです。

はじめから完成形を目指す必要はありません。まずは議事録化と、数値確認のように安全なタスクだけを回すところから始め、慣れてきたら実行スキルを一つずつ増やしていきます。あわせて、各タスクに「結果に責任を持つ人」を一人決めておくと、自動化が進んでも判断の所在が曖昧になりません。踏み込んだ判断を伴う領域は、精度と信頼が積み上がってから、範囲を少しずつ広げていきます。

まとめ ― 会議を「実行が動き出す起点」に変える

会議後タスクの自動化とは、会議を「話して終わる場」から「実行が動き出す起点」に変える取り組みです。多くのチームで、会議そのものより「そのあとの実行」がボトルネックになっています。決めたのに動かない、議事録は残るのに実行に落ちない。ここを仕組みで埋められれば、会議の一つひとつが確実に前進につながります。

必要なのは議事録の文字起こしだけ。会議を分類し、後続タスクを推察して担い手を仕分け、複数のスキルをオーケストレーションして実行まで回す。そのうえで、承認とフィードバックという要所だけを人が握る。この設計にすると、速さと納得感、そしてチームの文脈の共有が同時に手に入ります。AIに任せるのは実行や効率で、事業にとって何を優先するかの意思決定は手放さない——この線引きは、AIに意図を正しく伝える設定作法とも共通する考え方です。

始めるなら、いきなり全社の全会議を対象にする必要はありません。まずは、成果物が定型で判断しやすい会議——たとえば週次の定例——を一つ選び、議事録化と数値確認のような安全なタスクだけを自動化してみる。そこで「AIが出す下ごしらえが実際に役立つか」を確かめられれば、扱うタスクを一つずつ増やし、対象の会議を広げていけます。小さく始めて、信頼が積み上がってから範囲を広げる。この進め方が、無理なく定着させるための現実的な道筋です。

当社では、単発のAI活用にとどまらず、スキルのオーケストレーションによる後続処理の自動化や、人の承認を組み込んだ業務の流れの設計・運用まで伴走しています。自社のどの会議から仕組み化すればよいか迷われた際は、お問い合わせください。

参考・引用元

• 7garden／daiki「MTGが終わったらネクストアクションをAIが自動実行してくれるようにした」（Zenn） https://zenn.dev/7garden/articles/circleback-notion-ticket-auto-execution
• Anthropic「Effective context engineering for AI agents」 https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Anthropic「Agent Skills / Skill authoring best practices」 https://docs.claude.com/en/docs/agents-and-tools/agent-skills/best-practices
• Acrosstudio／シンウフム「もうプロンプトを書くな──Loop Engineering」（検証ゲート・停止条件）（Zenn） https://zenn.dev/acrosstudioblog/articles/38509c0473683a

※本文は上記の公開情報および当社の運用知見をもとに再構成したものです。事例は特定の企業・案件を指すものではありません。