Tiroがビジネス文脈を記憶する方法 ― MCP, API, CLI, Skill
「うちのチーム、AIツールは全部入れたのに、肝心の会議で何が決まったのかをAIが知らないんです」
AXを始めたチームが最初にぶつかる壁です。Notionをつなぎ、Jiraも連携し、SlackもMCPで開きました。それでも、このすべてのデータを生み出した源泉――つまり「なぜこの決定が下されたのか」を抱える会議の文脈は、AIエージェントの手が届かないところ にあります。
理由はシンプルです。ビジネス文脈の90%は口頭の会話で発生し、デジタル化されないまま消えていきます。Notionにまとめられたドキュメント、Jiraに上がったチケット、Slackに残ったメッセージ。これらは全体の文脈のたった10%にすぎません。残りの90%は「あの会議で誰がなぜそう発言したのか」の中にあり、誰も記録しなければ次の会議までに消えてしまいます。
この空白の90%をAIに渡す仕事を Conversation Intelligence と呼びます。会議の音声を受け取って、AIがそのまま読める形に変換しておくわけです。ただ、変換しただけでは終わりません。 どうつなぐか によって、AIの動き方がまるごと変わってしまうんです。
前回の記事では、AIエージェントが外部システムと協働するための4つの道具(API、MCP、CLI、Skill)の違いを整理しました。今回はもう一歩踏み込んで、消えていく90%の文脈をAIエージェントにつなぐために、4つの道具をどう使い分けるべきか。 Tiroがこの課題をどう解いているのかを具体的にお見せします。
AX 5-Layerで最も大きな空白
AXには5つのレイヤーがあります。 Context Source → Ontology → AI Model → Agentic Workflow → User Interface。上の3レイヤー(AI Model、Agentic Workflow、UI)ではすでに激しい競争が起きています。ClaudeやGPTのようなモデルは毎月賢くなり、n8nやZapierのようなワークフローツールは誰でも使え、Slackやターミナルはすでに優れたUIです。
ところが、土台にある2つのレイヤー、Context SourceとOntologyは、多くの組織で空白のままです。とくに Context Sourceで最も大きな空白は会議と対話のデータ です。これらのデータは音声として存在し、終わった瞬間に消え、誰かが意図的に変換しない限りAIはアクセスできません。
この空白を埋めるソフトウェアを Conversation Intelligence と呼びます。音声の会議データを受け取り、AIが活用できる形、すなわち LLM-Ready Data に変換すること が中核的な役割です。
文脈をデジタル化することと、エージェントにつなぐことは別の話です
ただし、文脈を デジタル化 するだけでは半分でしかありません。残り半分は、その文脈をAIエージェントが 実際に使える形でつなぐ ことです。1件の議事録が数千〜数万トークンになる世界では、つなぎ方を誤るとエージェントはむしろ遅くなります。
前回の記事の核心を一行で表すとこうです。同じデータでも、AIエージェントがどの道具でアクセスするかによって、結果が向かう先が変わる。 APIを使えばコードが好きな場所に送り、MCPを使えばチャットボットがその場で答え、CLIを使えばフォルダにファイルとして落ち、Skillを使えば次の作業の手順につながります。4つの道具は互いに代替するものではなく、成果物の行き先が違う補完関係 にあります。
Conversation Intelligence製品にとって、この原則はとくに重要です。扱うデータが本質的に重いから です。1時間の議事録1件で数千〜数万トークン、音声ファイルは1件で数百MBに達することもあります。ノート30件を一度に取得すれば百科事典1巻分のボリュームになります。ひとつの道具にすべてを詰め込めば、AIが一度に持っていられる量はすぐに超えてしまいます。
そこでTiroはAPI、MCP、CLI、Skillの4つすべてに対応しています。
詳しい仕様は api-docs.tiro.ooo で確認できます。
API:すべての骨格
TiroのAPIの下に、45のメソッドが4つのドメイン(Notes, Folders, Voice Files, Word Memory)に広がっています。他のSaaSと連携したり、自社バックエンドから呼び出したり、社内ツールを作ったり――そのすべての出発点です。
APIが本領を発揮するのは エージェントの推論が要らない作業 です。たとえば、営業チームの会議が終わったら自動でSalesforceに記録されるようにする、毎週月曜の朝に先週分の会議要約がNotionの1ページにまとまっている、といった作業。こうしたものは、IT部門が一度連携をつないでおけば、それ以降は人の手が要りません。
ちなみにMCPもCLIも、内部では結局このAPIを呼んでいます。だからこのAPIを「骨格」と呼んでいます。
💻 実際の呼び出し例は、記事末の 「📎 付録」 セクションにまとめています。
MCP:軽い文脈だけをコンテキストに入れる
MCPは、チャットボットが会議データに直接手を伸ばせるようにする道筋です。ClaudeやChatGPTに「先週の会議で決まったことのうち、まだ進んでいないものは?」と聞くと、チャットボットがMCPを通って中を見にいき、その場で答えてくれる――そんな仕組みです。
TiroのMCPサーバーは14のツールを6つの領域に整理しています。Authentication、Notes Discovery、Notes Retrieval、Templates、Share Links、Folders。
設計の核心は トークン予算を段階的に使わせること です。英語ではProgressive Disclosureと呼ばれる3段階のパターンで動きます。
1段階。 「どんな会議があった?」のような質問は、会議のリストと短いマッチ情報だけで答えが出ます。そこで list_notes または search_notes でメタデータとマッチスニペットだけを先に取得します。ノートあたり数十〜数百トークン、段落1つ分のボリューム。 「どんな会議があった?」 のような質問はたいていここで完結します。
2段階。 本文が要るノートだけを選んで get_note で取得します。include オプションで要約や作成された文書を選べ、要約は200〜800トークン程度です。
3段階。 本当に発話そのものが要るときだけ get_note_transcript で議事録全体を呼び出します。3,000〜5,000トークンで、短編小説1本分のボリュームです。
こうしてステップを分けることで、一般的な検索・要約シナリオでトークン使用量を90%以上削減できます。10件の会議の中から1件を見つけるとき、議事録を10件まるごと呼び出せばおよそ30,000トークンですが、list_notes(リストだけ)→ get_note(候補だけ要約)のパターンならおよそ800トークンで済みます。
MCPが本領を発揮するのは チャットボットと何度かやりとりしながら判断を絞り込む作業 です。 「先週の会議で出た決定事項のうち、まだ進んでいないものは?」 のような質問が代表例。リストを見て、必要なノートだけを選んで summary を取得し、判断を下す――この一連の推論こそがMCPの領域です。
CLI:重い荷物はフォルダに置く
四半期レビューが近づいてきたとしましょう。過去90日間に顧客と行った会議12件をすべて広げて、議事録を取っておく必要があります。これをすべてMCPで呼び出せば、チャットボットが一度に持っていられる量を大きく超えてしまいます。
CLIは、こうした大きな荷物をフォルダに落としておく道筋です。コマンド1行で、過去90日分の議事録12件がフォルダにマークダウンで落ちてきます。チャットボットの手に渡るのは「どこに保存され、サイズはいくつか」というレシート1枚だけなので、チャットボットは重くなりません。
同じ作業をMCPで行えば get_note_transcript を12回呼び出すことになり、その都度transcript本体がコンテキストウィンドウに流れ込みます。12件なら60〜600KBの dead weight です。CLIは結果を disk に送り、context にはパスとメタデータだけを残します。
CLIが本領を発揮するのは bulk作業と自動化 です。週次レポートの自動生成、CI/CDでの会議データ処理、cronによる定期export。disk と pipe が自然なあらゆる場面でCLIが働きます。
💻 実際のコマンド例も、記事末の付録にまとめています。
Skill:うちのチームだけの手順マニュアル
ここから話がもう一段深くなります。API、MCP、CLIは道具です。道具は使い方を知って初めて価値が生まれます。その 使い方 を書き残すのがSkillです。
Skillは SKILL.md というマークダウンファイルに手続き的知識を書いたものです。データを取得したり行動を起こしたりはしません。 「このタスクをやるときはこの順序で、こういう道具を使え」 というガイドを書いておけば、エージェントがその手順どおりに実行します。
なぜこれが重要かというと、同じConversation Intelligenceのデータでも、組織ごとに使い方が違うから です。コンサル会社は顧客ミーティングの要約をCRMにつなぎ、プロダクトチームはスプリントレビューで出た決定をLinearのIssueにし、人事チームは面接記録をオンボーディング資料に変えます。データソースは同じでも、ワークフローはまったく違います。
いくつかの実例を見てみましょう。
週次指標レビュー Skill
---
name: weekly-metric-review
description: 週次AARRR指標レビュー会議から決定事項と文脈を抽出するときに使う
---
## 手順
1. 今週の指標レビュー会議を検索する
`tiro notes search "AARRR" --since 7d --json > metrics.jsonl`
2. 各会議のtranscriptをdiskに保存する
`cat metrics.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./reviews/{}.md`
3. ./reviews/ 配下の .md を読み、次の基準で整理する
- 数字変化の *理由*(なぜこの指標が上がった/下がったのか)
- 決定事項と担当者
- 翌週までの実験リスト
4. 結果をNotionの週次レビューページに更新する
顧客ミーティング四半期レビュー Skill
---
name: quarterly-client-review
description: 特定顧客の過去90日のミーティングを総合し、四半期レビューを作成するときに使う
---
## 手順
1. 顧客名で過去90日の会議を検索する
`tiro notes search "<顧客名>" --since 90d --json > client.jsonl`
2. transcriptをdiskに保存する
`cat client.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./client-reviews/{}.md`
3. transcript全体を読み、次の基準で四半期レビューを作成する
- 主要論点の推移
- 未解決のイシューとリスク
- 関係性の健全度(ポジティブ/ネガティブシグナル)
4. 結果をSlackの #account-reviews チャンネルに投稿する
パターンが見えますか? CLIが重いデータをdiskに敷き、MCPが軽いmetadataで判断を下し、Skillがその順序を覚えている。 前回の記事の比喩を借りるなら、足が荷物を運び、手が精密にさばき、体に染みついた手順が順番を覚えている――そんな構造です。
Read → Reason → Act → Learn
Skillが単なるスクリプト集ではない理由があります。よく設計されたSkillは 循環構造 を作り出します。
Read. CLIで会議の文脈をdiskに取り込みます。MCPでメタデータと要約を読みます。
Reason. エージェントが集めた文脈をもとに判断します。 「この顧客は過去3回のミーティングで同じ不満を繰り返している」 、 「この指標が3週連続で下降している」 といったパターン認識。
Act. 判断に従って行動します。LinearにIssueを作る、Slackに通知を送る、レポートを生成する。
Learn. 行動の結果が次の会議で再び議論されます。その会議もまたTiroに記録され、次回のSkill実行で参照されます。ループが閉じます。
Tiroを導入することは、録音機を導入することではありません。ワークフローを導入すること です。会議 → 文脈の保存 → エージェントの実行 → 結果のフィードバック → 次の会議。この循環が回り出したとき、組織の会議はようやく 資産 になります。
文脈の重い製品が陥りやすい罠
この設計はTiroに限った話ではありません。Conversation Intelligenceに限らず、文脈が自然に重くなるあらゆる製品 に当てはまります。前回の記事ではScalekitの「32倍のトークン差」ベンチマークを紹介しましたが、MCPひとつにすべてを載せればコンテキストウィンドウは破綻し、CLIひとつで処理しようとすれば multi-turn reasoning を失います。
AX導入を検討しているチームがあるなら、まずこの問いを立ててみてください。
うちの組織で、AIがアクセスできない文脈はどこにありますか? そしてその文脈をAIにつなぐとき、成果物はエージェントのコンテキスト内にあるべきでしょうか、それともファイルとして保存されればよいでしょうか?
最初の問いがContext Sourceレイヤーを指し示し、二つ目の問いが道具選びを指し示します。この二つに答えられたとき、AXは10%から動き始めます。
よくある質問
Q. Conversation Intelligenceとは何ですか?
会議や通話のような音声会話を受け取り、AIが活用できる形(LLM-Ready Data)に変換するソフトウェアです。AX 5-LayerアーキテクチャではContext Sourceレイヤーの中核領域にあたり、企業のビジネス文脈のうちデジタル化されていない90%(口頭会話)を埋める役割を担います。
Q. TiroのMCPにはどんな道具がありますか?
14のツールが6つの領域にまたがって用意されています。Notes Discovery(list_notes, search_notes)、Notes Retrieval(get_note, get_note_transcript)、Templates、Share Links、Folders、Authentication。Progressive Disclosureのパターンでトークンを段階的に使います。全リストは api-docs.tiro.ooo/mcp で確認できます。
Q. Skill.mdは誰が作るのですか?
組織のAX担当者やエンジニアが作ります。マークダウンファイル一つに手順を書くだけなので、コーディングの知識が必ずしも必要なわけではありません。重要なのは 「うちのチームが会議データをどんな順序でどこに使っているか」 を明文化することです。一度作っておけば、チーム全員が同じ手順を一貫して実行できます。
Q. MCPとCLIはいつ使い分ければよいですか?
成果物がどこに行くかが基準です。エージェントのコンテキスト内でreasoningに使われるならMCP、ファイルとして保存されるべきならCLIです。ノート1件の要約(数百トークン)はMCPで、transcript10件のバルクexport(数MB)はCLIで処理するのが自然です。詳しい決定木は前回の記事で扱っています。
Q. すでに議事録ツールを使っているのですが、何が違うのですか?
単なる議事録ツールは 記録 で止まります。Tiroが4つの道具(API、MCP、CLI、Skill)すべてに対応する理由は、記録された文脈がAIエージェントのワークフローまで流れ込んで初めて、AXが成立するからです。録音機を導入することと、ワークフローを導入することは違います。
さらに読む
はじめる
📎 付録
コードを直接見られる方向けに、本文から外しておいた呼び出し例をここにまとめます。
API呼び出し例
curl -H "Authorization: Bearer $TIRO_API_KEY" \
https://api.tiro.ooo/v1/external/notes
OpenAPI specを公開しているため、SDK自動生成やPostmanへのインポートも自由です。
CLI一括処理の例
tiro コマンドではtranscriptをdiskに保存し、検索結果をNDJSONでpipeで流し、jq と組み合わせます。
たとえば四半期レビューに向けて過去30日間の「Acme Corp」会議をすべて見つけ、transcriptをダウンロードする作業はこうなります。
# 検索 → メタデータをNDJSONで
tiro notes search "Acme Corp" --since 30d --json > /tmp/acme.jsonl
# 一件ずつtranscriptをdiskに保存
cat /tmp/acme.jsonl \
| jq -r '.guid' \
| xargs -I{} tiro notes transcript {} --format md --output ./out/{}.md
--output を使うとstdoutにはメタデータが1行だけ残ります。
{"saved":"./out/abc123.md","size":5234,"format":"md","guid":"abc123","paragraphCount":42}
Skillファイル例(週次指標レビュー)
---
name: weekly-metric-review
description: 週次AARRR指標レビュー会議から決定事項と文脈を抽出するときに使う
---
## 手順
1. 今週の指標レビュー会議を検索する
`tiro notes search "AARRR" --since 7d --json > metrics.jsonl`
2. 各会議のtranscriptをdiskに保存する
`cat metrics.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./reviews/{}.md`
3. ./reviews/ 配下の .md を読み、次の基準で整理する
- 数字変化の *理由*(なぜこの指標が上がった/下がったのか)
- 決定事項と担当者
- 翌週までの実験リスト
4. 結果をNotionの週次レビューページに更新する
API・MCP・CLIの全仕様は api-docs.tiro.ooo で確認できます。
「うちのチーム、AIツールは全部入れたのに、肝心の会議で何が決まったのかをAIが知らないんです」
AXを始めたチームが最初にぶつかる壁です。Notionをつなぎ、Jiraも連携し、SlackもMCPで開きました。それでも、このすべてのデータを生み出した源泉――つまり「なぜこの決定が下されたのか」を抱える会議の文脈は、AIエージェントの手が届かないところ にあります。
理由はシンプルです。ビジネス文脈の90%は口頭の会話で発生し、デジタル化されないまま消えていきます。Notionにまとめられたドキュメント、Jiraに上がったチケット、Slackに残ったメッセージ。これらは全体の文脈のたった10%にすぎません。残りの90%は「あの会議で誰がなぜそう発言したのか」の中にあり、誰も記録しなければ次の会議までに消えてしまいます。
この空白の90%をAIに渡す仕事を Conversation Intelligence と呼びます。会議の音声を受け取って、AIがそのまま読める形に変換しておくわけです。ただ、変換しただけでは終わりません。 どうつなぐか によって、AIの動き方がまるごと変わってしまうんです。
前回の記事では、AIエージェントが外部システムと協働するための4つの道具(API、MCP、CLI、Skill)の違いを整理しました。今回はもう一歩踏み込んで、消えていく90%の文脈をAIエージェントにつなぐために、4つの道具をどう使い分けるべきか。 Tiroがこの課題をどう解いているのかを具体的にお見せします。
AX 5-Layerで最も大きな空白
AXには5つのレイヤーがあります。 Context Source → Ontology → AI Model → Agentic Workflow → User Interface。上の3レイヤー(AI Model、Agentic Workflow、UI)ではすでに激しい競争が起きています。ClaudeやGPTのようなモデルは毎月賢くなり、n8nやZapierのようなワークフローツールは誰でも使え、Slackやターミナルはすでに優れたUIです。
ところが、土台にある2つのレイヤー、Context SourceとOntologyは、多くの組織で空白のままです。とくに Context Sourceで最も大きな空白は会議と対話のデータ です。これらのデータは音声として存在し、終わった瞬間に消え、誰かが意図的に変換しない限りAIはアクセスできません。
この空白を埋めるソフトウェアを Conversation Intelligence と呼びます。音声の会議データを受け取り、AIが活用できる形、すなわち LLM-Ready Data に変換すること が中核的な役割です。
文脈をデジタル化することと、エージェントにつなぐことは別の話です
ただし、文脈を デジタル化 するだけでは半分でしかありません。残り半分は、その文脈をAIエージェントが 実際に使える形でつなぐ ことです。1件の議事録が数千〜数万トークンになる世界では、つなぎ方を誤るとエージェントはむしろ遅くなります。
前回の記事の核心を一行で表すとこうです。同じデータでも、AIエージェントがどの道具でアクセスするかによって、結果が向かう先が変わる。 APIを使えばコードが好きな場所に送り、MCPを使えばチャットボットがその場で答え、CLIを使えばフォルダにファイルとして落ち、Skillを使えば次の作業の手順につながります。4つの道具は互いに代替するものではなく、成果物の行き先が違う補完関係 にあります。
Conversation Intelligence製品にとって、この原則はとくに重要です。扱うデータが本質的に重いから です。1時間の議事録1件で数千〜数万トークン、音声ファイルは1件で数百MBに達することもあります。ノート30件を一度に取得すれば百科事典1巻分のボリュームになります。ひとつの道具にすべてを詰め込めば、AIが一度に持っていられる量はすぐに超えてしまいます。
そこでTiroはAPI、MCP、CLI、Skillの4つすべてに対応しています。
詳しい仕様は api-docs.tiro.ooo で確認できます。
API:すべての骨格
TiroのAPIの下に、45のメソッドが4つのドメイン(Notes, Folders, Voice Files, Word Memory)に広がっています。他のSaaSと連携したり、自社バックエンドから呼び出したり、社内ツールを作ったり――そのすべての出発点です。
APIが本領を発揮するのは エージェントの推論が要らない作業 です。たとえば、営業チームの会議が終わったら自動でSalesforceに記録されるようにする、毎週月曜の朝に先週分の会議要約がNotionの1ページにまとまっている、といった作業。こうしたものは、IT部門が一度連携をつないでおけば、それ以降は人の手が要りません。
ちなみにMCPもCLIも、内部では結局このAPIを呼んでいます。だからこのAPIを「骨格」と呼んでいます。
💻 実際の呼び出し例は、記事末の 「📎 付録」 セクションにまとめています。
MCP:軽い文脈だけをコンテキストに入れる
MCPは、チャットボットが会議データに直接手を伸ばせるようにする道筋です。ClaudeやChatGPTに「先週の会議で決まったことのうち、まだ進んでいないものは?」と聞くと、チャットボットがMCPを通って中を見にいき、その場で答えてくれる――そんな仕組みです。
TiroのMCPサーバーは14のツールを6つの領域に整理しています。Authentication、Notes Discovery、Notes Retrieval、Templates、Share Links、Folders。
設計の核心は トークン予算を段階的に使わせること です。英語ではProgressive Disclosureと呼ばれる3段階のパターンで動きます。
1段階。 「どんな会議があった?」のような質問は、会議のリストと短いマッチ情報だけで答えが出ます。そこで list_notes または search_notes でメタデータとマッチスニペットだけを先に取得します。ノートあたり数十〜数百トークン、段落1つ分のボリューム。 「どんな会議があった?」 のような質問はたいていここで完結します。
2段階。 本文が要るノートだけを選んで get_note で取得します。include オプションで要約や作成された文書を選べ、要約は200〜800トークン程度です。
3段階。 本当に発話そのものが要るときだけ get_note_transcript で議事録全体を呼び出します。3,000〜5,000トークンで、短編小説1本分のボリュームです。
こうしてステップを分けることで、一般的な検索・要約シナリオでトークン使用量を90%以上削減できます。10件の会議の中から1件を見つけるとき、議事録を10件まるごと呼び出せばおよそ30,000トークンですが、list_notes(リストだけ)→ get_note(候補だけ要約)のパターンならおよそ800トークンで済みます。
MCPが本領を発揮するのは チャットボットと何度かやりとりしながら判断を絞り込む作業 です。 「先週の会議で出た決定事項のうち、まだ進んでいないものは?」 のような質問が代表例。リストを見て、必要なノートだけを選んで summary を取得し、判断を下す――この一連の推論こそがMCPの領域です。
CLI:重い荷物はフォルダに置く
四半期レビューが近づいてきたとしましょう。過去90日間に顧客と行った会議12件をすべて広げて、議事録を取っておく必要があります。これをすべてMCPで呼び出せば、チャットボットが一度に持っていられる量を大きく超えてしまいます。
CLIは、こうした大きな荷物をフォルダに落としておく道筋です。コマンド1行で、過去90日分の議事録12件がフォルダにマークダウンで落ちてきます。チャットボットの手に渡るのは「どこに保存され、サイズはいくつか」というレシート1枚だけなので、チャットボットは重くなりません。
同じ作業をMCPで行えば get_note_transcript を12回呼び出すことになり、その都度transcript本体がコンテキストウィンドウに流れ込みます。12件なら60〜600KBの dead weight です。CLIは結果を disk に送り、context にはパスとメタデータだけを残します。
CLIが本領を発揮するのは bulk作業と自動化 です。週次レポートの自動生成、CI/CDでの会議データ処理、cronによる定期export。disk と pipe が自然なあらゆる場面でCLIが働きます。
💻 実際のコマンド例も、記事末の付録にまとめています。
Skill:うちのチームだけの手順マニュアル
ここから話がもう一段深くなります。API、MCP、CLIは道具です。道具は使い方を知って初めて価値が生まれます。その 使い方 を書き残すのがSkillです。
Skillは SKILL.md というマークダウンファイルに手続き的知識を書いたものです。データを取得したり行動を起こしたりはしません。 「このタスクをやるときはこの順序で、こういう道具を使え」 というガイドを書いておけば、エージェントがその手順どおりに実行します。
なぜこれが重要かというと、同じConversation Intelligenceのデータでも、組織ごとに使い方が違うから です。コンサル会社は顧客ミーティングの要約をCRMにつなぎ、プロダクトチームはスプリントレビューで出た決定をLinearのIssueにし、人事チームは面接記録をオンボーディング資料に変えます。データソースは同じでも、ワークフローはまったく違います。
いくつかの実例を見てみましょう。
週次指標レビュー Skill
---
name: weekly-metric-review
description: 週次AARRR指標レビュー会議から決定事項と文脈を抽出するときに使う
---
## 手順
1. 今週の指標レビュー会議を検索する
`tiro notes search "AARRR" --since 7d --json > metrics.jsonl`
2. 各会議のtranscriptをdiskに保存する
`cat metrics.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./reviews/{}.md`
3. ./reviews/ 配下の .md を読み、次の基準で整理する
- 数字変化の *理由*(なぜこの指標が上がった/下がったのか)
- 決定事項と担当者
- 翌週までの実験リスト
4. 結果をNotionの週次レビューページに更新する
顧客ミーティング四半期レビュー Skill
---
name: quarterly-client-review
description: 特定顧客の過去90日のミーティングを総合し、四半期レビューを作成するときに使う
---
## 手順
1. 顧客名で過去90日の会議を検索する
`tiro notes search "<顧客名>" --since 90d --json > client.jsonl`
2. transcriptをdiskに保存する
`cat client.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./client-reviews/{}.md`
3. transcript全体を読み、次の基準で四半期レビューを作成する
- 主要論点の推移
- 未解決のイシューとリスク
- 関係性の健全度(ポジティブ/ネガティブシグナル)
4. 結果をSlackの #account-reviews チャンネルに投稿する
パターンが見えますか? CLIが重いデータをdiskに敷き、MCPが軽いmetadataで判断を下し、Skillがその順序を覚えている。 前回の記事の比喩を借りるなら、足が荷物を運び、手が精密にさばき、体に染みついた手順が順番を覚えている――そんな構造です。
Read → Reason → Act → Learn
Skillが単なるスクリプト集ではない理由があります。よく設計されたSkillは 循環構造 を作り出します。
Read. CLIで会議の文脈をdiskに取り込みます。MCPでメタデータと要約を読みます。
Reason. エージェントが集めた文脈をもとに判断します。 「この顧客は過去3回のミーティングで同じ不満を繰り返している」 、 「この指標が3週連続で下降している」 といったパターン認識。
Act. 判断に従って行動します。LinearにIssueを作る、Slackに通知を送る、レポートを生成する。
Learn. 行動の結果が次の会議で再び議論されます。その会議もまたTiroに記録され、次回のSkill実行で参照されます。ループが閉じます。
Tiroを導入することは、録音機を導入することではありません。ワークフローを導入すること です。会議 → 文脈の保存 → エージェントの実行 → 結果のフィードバック → 次の会議。この循環が回り出したとき、組織の会議はようやく 資産 になります。
文脈の重い製品が陥りやすい罠
この設計はTiroに限った話ではありません。Conversation Intelligenceに限らず、文脈が自然に重くなるあらゆる製品 に当てはまります。前回の記事ではScalekitの「32倍のトークン差」ベンチマークを紹介しましたが、MCPひとつにすべてを載せればコンテキストウィンドウは破綻し、CLIひとつで処理しようとすれば multi-turn reasoning を失います。
AX導入を検討しているチームがあるなら、まずこの問いを立ててみてください。
うちの組織で、AIがアクセスできない文脈はどこにありますか? そしてその文脈をAIにつなぐとき、成果物はエージェントのコンテキスト内にあるべきでしょうか、それともファイルとして保存されればよいでしょうか?
最初の問いがContext Sourceレイヤーを指し示し、二つ目の問いが道具選びを指し示します。この二つに答えられたとき、AXは10%から動き始めます。
よくある質問
Q. Conversation Intelligenceとは何ですか?
会議や通話のような音声会話を受け取り、AIが活用できる形(LLM-Ready Data)に変換するソフトウェアです。AX 5-LayerアーキテクチャではContext Sourceレイヤーの中核領域にあたり、企業のビジネス文脈のうちデジタル化されていない90%(口頭会話)を埋める役割を担います。
Q. TiroのMCPにはどんな道具がありますか?
14のツールが6つの領域にまたがって用意されています。Notes Discovery(list_notes, search_notes)、Notes Retrieval(get_note, get_note_transcript)、Templates、Share Links、Folders、Authentication。Progressive Disclosureのパターンでトークンを段階的に使います。全リストは api-docs.tiro.ooo/mcp で確認できます。
Q. Skill.mdは誰が作るのですか?
組織のAX担当者やエンジニアが作ります。マークダウンファイル一つに手順を書くだけなので、コーディングの知識が必ずしも必要なわけではありません。重要なのは 「うちのチームが会議データをどんな順序でどこに使っているか」 を明文化することです。一度作っておけば、チーム全員が同じ手順を一貫して実行できます。
Q. MCPとCLIはいつ使い分ければよいですか?
成果物がどこに行くかが基準です。エージェントのコンテキスト内でreasoningに使われるならMCP、ファイルとして保存されるべきならCLIです。ノート1件の要約(数百トークン)はMCPで、transcript10件のバルクexport(数MB)はCLIで処理するのが自然です。詳しい決定木は前回の記事で扱っています。
Q. すでに議事録ツールを使っているのですが、何が違うのですか?
単なる議事録ツールは 記録 で止まります。Tiroが4つの道具(API、MCP、CLI、Skill)すべてに対応する理由は、記録された文脈がAIエージェントのワークフローまで流れ込んで初めて、AXが成立するからです。録音機を導入することと、ワークフローを導入することは違います。
さらに読む
はじめる
📎 付録
コードを直接見られる方向けに、本文から外しておいた呼び出し例をここにまとめます。
API呼び出し例
curl -H "Authorization: Bearer $TIRO_API_KEY" \
https://api.tiro.ooo/v1/external/notes
OpenAPI specを公開しているため、SDK自動生成やPostmanへのインポートも自由です。
CLI一括処理の例
tiro コマンドではtranscriptをdiskに保存し、検索結果をNDJSONでpipeで流し、jq と組み合わせます。
たとえば四半期レビューに向けて過去30日間の「Acme Corp」会議をすべて見つけ、transcriptをダウンロードする作業はこうなります。
# 検索 → メタデータをNDJSONで
tiro notes search "Acme Corp" --since 30d --json > /tmp/acme.jsonl
# 一件ずつtranscriptをdiskに保存
cat /tmp/acme.jsonl \
| jq -r '.guid' \
| xargs -I{} tiro notes transcript {} --format md --output ./out/{}.md
--output を使うとstdoutにはメタデータが1行だけ残ります。
{"saved":"./out/abc123.md","size":5234,"format":"md","guid":"abc123","paragraphCount":42}
Skillファイル例(週次指標レビュー)
---
name: weekly-metric-review
description: 週次AARRR指標レビュー会議から決定事項と文脈を抽出するときに使う
---
## 手順
1. 今週の指標レビュー会議を検索する
`tiro notes search "AARRR" --since 7d --json > metrics.jsonl`
2. 各会議のtranscriptをdiskに保存する
`cat metrics.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./reviews/{}.md`
3. ./reviews/ 配下の .md を読み、次の基準で整理する
- 数字変化の *理由*(なぜこの指標が上がった/下がったのか)
- 決定事項と担当者
- 翌週までの実験リスト
4. 結果をNotionの週次レビューページに更新する
API・MCP・CLIの全仕様は api-docs.tiro.ooo で確認できます。