はじめに
株式会社Roundaでインターンをしている上治です。本記事では、すでにNotion上に用意された会議の文字起こしデータを基に、自動で「ナレッジ要素」と「タスク要素」に分類し、BacklogのWikiと課題へそれぞれ書き出すシステムをご紹介します。記事通りに実装すれば、お手元のパソコンから動作を体験いただけます。(本記事でのナレッジとは、組織が蓄積・共有すべき知見・ノウハウを指します)
読者としては以下の方々を想定しています。
- MCPに興味のある方
- 外部サービス（Notion／Backlog）と LLM を連携させたい方
- Notion や Backlog を既にプロジェクト運用で使っていて、その運用効率化に興味のある方
ユースケース
クライアントとITコンサルタントの会議が行われました。それを文字起こししたものが、Notionのページに存在します。文字起こしから、ナレッジ要素をBacklogのWikiページに、タスク要素をBacklogの課題ページに書き出したいという場面を想定します。
以下のように、notionに文字起こしの内容をもとに、Backlogへ書き出します。
- 文字起こしのナレッジ要素 → BacklogのWiki
- 文字起こしのタスク要素 → Backlogの課題
図は、会議が行われてからBacklogに書き出されるまでの流れを表します。
MCPサーバーについて
上図にも記されているMCPサーバーについてそもそもどんなものなのか解説します。
MCPとはModel Context Protocolの略で、これはAnthropicによって提唱されました。
簡単に言うと、Claude等のLLMアプリケーションと外部データソース/ツールを接続するための標準規格のことです。以下の図[1]のように、MCPの登場により、ツールごとのAPIを実装する必要がなくなり、LLMが複数のツールと動的に接続できるようになりました。
MCPなし（左）とMCPあり（右）の比較[1]
以下の図[1]はMCPのワークフローを表します。MCPクライアントがLLMアプリケーション(Claude等)に該当し、外部ツール側がMCPサーバーを提供しています。ユーザーがMCPクライアントにプロンプトを送ってからの主な流れは、以下のとおりです。
- ユーザーが MCP クライアントにプロンプトを送信
- クライアントが内容を解析し、MCP サーバーを介して適切なツール(操作)を選択
- MCPサーバーの Resources 機能によって、必要なデータを取得・加工
- 加工結果をクライアント経由で LLM に返却し、最終的な出力を生成
MCPサーバーの構造[1]
今回は、NotionおよびBacklogによって提供されているMCPサーバーを使います。
Notion：情報の一元管理と共有を目的とした多目的プラットフォーム
Backlog：タスク・プロジェクト管理に特化したツール
事前準備
前提
- Claude Desktopがインストールされている(ClaudeはProプラン）
- Docker Desktopがインストールされていて、「docker run」や「docker build」等のコマンドが使える状態
- WSLがインストールされている
- Notionのアカウントを持っている
- Backlogのアカウントを持っていて、仮のプロジェクト,ダミーの課題が1つある。
1.Notionの事前準備
MCPサーバーを使う
NotionのMCPサーバーを使うためのコンテナは、Docker hubに存在しているため、「git clone」というコマンドを打つ必要はありません。
APIアクセストークンの作成&インテグレーションの追加
APIアクセストークン(ntn_から始まる)を作成します。次に、MCPにアクセスさせたいページに、今作ったインテグレーションを追加してください。いずれも以下のNotion MCPの記事を参考にしました。
文字起こしを記載したページを作成
MCPにアクセスできるページに、会議の文字起こしを置いておきます。ChatGPTに1時間程度を想定して作成してもらいました。A社の在庫管理システムに関するプロジェクトのキックオフ会議の内容となります。
本記事では、「Project」というページにインテグレーションを追加し、そこに「5/15_ITコンサルタントとクライアントの会議文字起こし」という子ページを作成しました。以下はリンクから見ることができます。
2.Backlogの事前準備
MCPサーバーを使う
BacklogのMCPサーバーを使うために、
MCPが実装されたリポジトリ[3]をクローンし、そこにあるdockerfileをもとに、イメージをビルドします。
WSL上で以下のコマンドを打ってください。
$ git clone https://github.com/fleagne/backlog-mcp-server.git
$ cd backlog-mcp-server
$ docker build -t backlog-mcp-server:local .
APIキーの取得
以下のBacklog公式記事を参考に、APIキーを取得してください。
プロジェクトにダミーの課題を追加
以下の図のように、プロジェクトを作成し、そこにダミーの課題を手動で追加してください。
ダミーの課題が存在しないと、Claudeが「課題はどのような項目で構成されているか」、「各項目はどの型か」を理解できないため、エラーが出てしまいいます。
これに関する詳細の仕組みは以下の通りです：
- MCPサーバー側: MCPサーバーは、利用可能なツール（関数）とその引数の型定義をJSON Schema形式で定義・公開します。
- Claude（MCPクライアント）側: Claudeがツールを呼び出す際、既存の課題データを参照して、新しい課題を追加するために必要な型情報（フィールド名、データ型、必須項目など）を理解します。
- ダミーデータの役割: Backlogの場合、既存の課題が存在しないと、MCPサーバーがClaudeに対して「課題にはどのようなフィールドがあるか」「各フィールドはどの型か」を適切に伝えることができません。
([5]を参考にしました)
3.Claude Desktopの事前準備
Claudeに、NotionとBacklogのMCPサーバーを認識させるために、claude_desktop_config.jsonを編集します。
以下の画像のように、Cluade Desktopの左上の三本線→「ファイル」→「設定」→「開発者」→「構成を編集」を押すと、claude_desktop_config.jsonを開くことができます。
以下のように、claude_desktop_config.jsonを書いてください。
ただし、Notionに関しては、your notion api access tokenに、ntnから始まる自分のAPIアクセストークンを挿入してください。
backlogに関しては、your backlog api keyに自分のapi keyを、your backlog space idには、自分のspace id(〇〇.backlog.com の〇〇の部分)
を挿入してください。
{
"mcpServers":{
"notionApi": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"-e", "OPENAPI_MCP_HEADERS",
"mcp/notion"
],
"env": {
"OPENAPI_MCP_HEADERS": "{\"Authorization\":\"Bearer **your notion api access token**\",\"Notion-Version\":\"2022-06-28\"}"
}
},
"backlog": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"BACKLOG_API_KEY",
"-e",
"BACKLOG_SPACE_ID",
"backlog-mcp-server:local"
],
"env": {
"BACKLOG_API_KEY": "**your backlog api key**",
"BACKLOG_SPACE_ID": "**your backlog space id**"
}
}
}}
以下のスクリーンショットのように、Claude Desktop上で「検索とツール」クリックし、backlogとnotionApiが表示されていれば、準備完了です。
検証
では、実際に動かしてみましょう。
ユースケース1
Notionの「5/15_ITコンサルタントとクライアントの会議文字起こし」を基に、backlogの「Project」に書き出して。 ただし、
- ナレッジ要素はbacklogのwikiに
- タスク要素はbacklogの課題に分割
- 課題の説明に、その課題の完了基準を書いて
Claudeの出力
Claudeによって選択されたツール一覧です。プロンプトからClaudeが適切なツールを考え、それにより、NotionやBacklogのMCPサーバーにリクエストを送ります。そのリクエストに応じて、MCPサーバーはレスポンスを返したり、Backlogのデータベースを編集します。
-
API-post-seach:Notion内で指定された単語を探す
-
API-retrieve-a-page:Notion内で単語の存在するページを取り出す
-
API-get-block-children:Notionのページ内の子ブロック「5/15_ITコンサルタントとクライアントの会議文字起こし」を取り出す
-
backlog_get_projects:存在するプロジェクトを調べる
-
backlog_get_add_wiki:wikiを追加する
-
backlog_get_issues:存在する課題を調べ、型を得る
-
backlog_get_add_issue:課題を追加する
Claudeにプロンプトを送るだけで、実際にBacklogのプロジェクトにWikiや課題が追加されます。
Wikiは以下の通りで、内容としては、プロジェクト概要、現状の課題、システム要件、提案内容、費用感、データマイグレーション方針、リスクと対応策、サポート内容、プロジェクトスケジュールが記されています。
Backlogに追加されたWiki
プロジェクト概要
A社の在庫管理システム刷新プロジェクトに関する情報をまとめます。
現状の課題
- 在庫管理システムがレガシーで、データ更新が手作業
- 二重入力ミスやタイムラグが月に数十件発生
- 更新は日次バッチで実行
- 平均30件/週の在庫誤差が発生
- 月間で顧客クレームが10〜15件
- 出荷部門でピッキングミスや納期遅延が増加
- 人手による確認工数も増加
システム要件（優先順位）
- リアルタイム在庫更新
- 可視化ダッシュボード
- モバイルアクセス対応
提案内容
全体提案（当初）
- マイクロサービスアーキテクチャによる在庫API
- イベントストリーミング基盤（Kafka＋Flink）
- BIダッシュボード（Power BI）
- モバイルアプリ（React Native）
MVP（予算調整後）
- 在庫API
- BIダッシュボード
- Keycloakによる認証連携（OAuth2/SAML対応）
- 自動レポート生成（オプション追加）
第二フェーズ（将来対応）
- モバイルアクセス対応
費用感
- 導入フェーズ: 1,200万円（当初提案、MVPは要調整）
- 月次保守: 50万円/月
データマイグレーション方針
- 増分バッチ＋スナップショット検証方式
- ダウンタイムを最小化
リスクと対応策
- 認証ミス対応: PAMテスト
- データ不整合対応: 自動検証スクリプト
- 研修不足対応: オンライン＋対面での研修実施
サポート内容
- 導入時にハンズオン研修
- 運用後は月次サポート契約
プロジェクトスケジュール
マイルストーン
- 6/1：要件定義完了
- 7/1：設計完了
- 9/1：開発完了
- 10/15：総合テスト開始
- 10/31：本番リリース
次回ミーティング
- 日時：6/3 10:00
- 議題：インフラ要件と予算調整
文字起こしから、課題は9件抽出されました。
- 要件定義書ドラフト作成 (期限: 2025-05-27)
- ROIレポート作成 (期限: 2025-05-29)
- 次回MTG：インフラ要件と予算調整 (期限: 2025-06-03)
- 在庫API設計 (期限: 2025-06-20)
- BIダッシュボード設計 (期限: 2025-06-20)
- データマイグレーション計画策定 (期限: 2025-06-30)
- リスク管理計画策定 (期限: 2025-06-15)
- 研修計画策定 (期限: 2025-07-15)
- 予算調整案作成 (期限: 2025-06-05)
*PROJECT-1 顔合わせはダミーの課題です。
例えば以下の写真は、Backlog上での1つめの課題「要件定義書ドラフト作成」で、完了基準・背景情報も含まれています。プロンプトでお願いした完了基準についても反映されています。
ユースケース2:課題の担当者を割り振る
いまは、課題に担当者は設定されていません。そこで次は、担当者の割り振りを行う場面を想定します。ただし、ユースケース1を実行してBacklogに書き出しが行われた後に、追加で実行しました。
まずは、もとはメンバーAだけでしたが、メンバーBとメンバーCをプロジェクトメンバーに追加し、仮で3人のチームとしました。nulabのアカウントを人数分作成し、招待する必要があります。
つぎに、3人のメンバーの役割を記載した文章を手動でWikiに追加します。
さらに、ダミーの課題を2つ作り、それぞれの担当者を手動でメンバーB, メンバーCと設定しました。この設定がないと、ClaudeがメンバーBとメンバーCのユーザーIDを知ることができず、担当者の割り振りをすることができませんでした。
実際のClaude上のチャットのリンクです。
Backlogのwikiの「プロジェクトメンバー役割」を基に、存在する課題の担当者を設定してください。
Claudeの出力(ただしツールは省略されている)
プロジェクトメンバーの役割に基づいて課題の担当者を設定するために、まずBacklogからプロジェクト情報とwiki情報を取得します。
まず、プロジェクト情報を確認しましょう。
次に、このプロジェクトのwikiページを取得し、「プロジェクトメンバー役割」に関するwikiページを探します。
「プロジェクトメンバー役割」のwikiページが見つかりました（ID: 4458914）。次に、このwikiページの内容を取得します。
次に、現在の課題一覧を取得して、どの課題が担当者未設定かを確認します。
ここでwikiの「プロジェクトメンバー役割」の内容と課題一覧を分析します。
Wikiから役割の情報：
1. プロジェクトリーダー：メンバーA
- 施策全体の統括、クライアント折衝、スケジュール管理、品質保証
- チーム間調整と最終的な意思決定
2. ビジネスアナリスト：メンバーB
- クライアントからのヒアリング内容の整理、要件の明確化・文書化
- ビジネス上のニーズと技術要件をつなぐ
3. ソリューションアーキテクト：メンバーC
- システム全体の設計方針の策定、技術要件の具体化
- 技術スタックや連携方式の選定、設計の妥当性担保
担当者が設定されていない課題：
- PROJECT-2: 要件定義書ドラフト作成
- PROJECT-3: ROIレポート作成
- PROJECT-4: 次回MTG：インフラ要件と予算調整
- PROJECT-5: 在庫API設計
- PROJECT-6: BIダッシュボード設計
- PROJECT-7: データマイグレーション計画策定
- PROJECT-8: リスク管理計画策定
- PROJECT-9: 研修計画策定
- PROJECT-10: 予算調整案作成
各メンバーの役割に基づいて課題を割り当てます：
1. メンバーA (プロジェクトリーダー):
- PROJECT-4: 次回MTG：インフラ要件と予算調整 (プロジェクト全体統括のため)
- PROJECT-10: 予算調整案作成 (プロジェクト全体の予算管理のため)
- PROJECT-8: リスク管理計画策定 (プロジェクト全体のリスク管理のため)
2. メンバーB (ビジネスアナリスト):
- PROJECT-2: 要件定義書ドラフト作成 (要件の明確化・文書化のため)
- PROJECT-3: ROIレポート作成 (ビジネス上のニーズを数値化するため)
- PROJECT-9: 研修計画策定 (クライアントへの展開などを考慮するため)
3. メンバーC (ソリューションアーキテクト):
- PROJECT-5: 在庫API設計 (技術設計のため)
- PROJECT-6: BIダッシュボード設計 (技術設計のため)
- PROJECT-7: データマイグレーション計画策定 (技術面での移行計画のため)
それでは、各課題に担当者を設定していきます。
まず、メンバーA（プロジェクトリーダー）に課題を割り当てます：
次に、メンバーB（ビジネスアナリスト）に課題を割り当てます：
最後に、メンバーC（ソリューションアーキテクト）に課題を割り当てます：
全ての課題に担当者が割り当てられました。以下に割り当て結果をまとめます：
1. メンバーA（プロジェクトリーダー）担当：
- PROJECT-4: 次回MTG：インフラ要件と予算調整
- PROJECT-8: リスク管理計画策定
- PROJECT-10: 予算調整案作成
- PROJECT-11: ダミー（既に割り当て済み）
2. メンバーB（ビジネスアナリスト）担当：
- PROJECT-1: ダミー（既に割り当て済み）
- PROJECT-2: 要件定義書ドラフト作成
- PROJECT-3: ROIレポート作成
- PROJECT-9: 研修計画策定
3. メンバーC（ソリューションアーキテクト）担当：
- PROJECT-5: 在庫API設計
- PROJECT-6: BIダッシュボード設計
- PROJECT-7: データマイグレーション計画策定
Backlogのwikiに記載されているプロジェクトメンバーの役割に基づいて、各メンバーの専門性と役割に合った課題の担当者を設定しました。
- プロジェクトリーダー（メンバーA）には全体の統括、予算管理、リスク管理など
- ビジネスアナリスト（メンバーB）には要件定義、ROI分析、研修計画など
- ソリューションアーキテクト（メンバーC）には技術設計、API設計、データ移行など
これにより、各メンバーの専門性を活かした効率的なタスク割り当てが完了しました。
Backlog上の画面でも担当者が更新されています。
今後の展望
Backlogの他の機能の使用
Backlogには親子課題、ガントチャート、カンバンボードなど、プロジェクト管理を円滑に進めるための多彩な機能があります。MCPを介してこれらを扱う実装はまだありませんが、LLMから直接操作できるようになると、例えば以下のようなメリットが期待できます。
-
親子課題の自動生成・リンク付け
階層構造を持つタスクをLLMが自動で作成・紐づけし、複雑なプロジェクトでも抜け漏れなく管理できる。 -
ガントチャートのリアルタイム更新
スケジュールや依存関係をLLMが解析して自動でガントを再描画し、進捗や遅延を即座に可視化。 -
カンバンボードのステータス移動
タスクの状態変更（To Do→In Progress→Doneなど）をLLMが判断・実行し、チームがリアルタイムで最新状況を把握。
これにより、日々のタスク管理工数が削減されるだけでなく、プロジェクト全体の透明性とスピードが飛躍的に向上します。
音声ファイルからの書き出し
今回はあらかじめNotionに会議の文字起こしを記載したページを準備しました。よりユーザーが快適に使えるために、会議で録音された音声ファイルだけが存在した状態から、Backlogに書き出せるようにような機能も付けたいと思いました。実現には声色から人を特定する必要もあると思います。
ダミーの課題が無い場合での処理
今回は、ダミーの課題がないと、Claudeが正しい型を取得できなかったので、手動で追加するという方法を選びました。しかし、その手間を省くために、MCPからClaudeに型を伝える部分のコードを編集し、課題が空のときはデフォルトの型で生成できるようにすることが考えられます。
また、プロジェクトメンバーのユーザーIDに関しても、あらかじめ各メンバーが最低1つの課題に割り振られていないとClaudeがユーザーIDを取得することはできませんでした。この問題についてもMCPを構築するコードを見て工夫する必要があります。
文字起こしデータの拡張
現状のA社在庫管理システムを題材とした2人の会議から、より実践的な会議へ対応できるか検証が必要です。現実の会議は、以下の要素をもつことが考えられます。
- 大人数での会議
- 難易度の高い議題について話われて議論の途中で方向性が大きく変わる会議
このような複雑な議論の流れを正確に要約したり、最終的な結論のみを的確に抽出したりするためには、どのようにプロンプトを工夫するのか等の検証が考えられます。
職能情報とデータベース連携の強化
今回ユースケース2で担当者の割り振りを行う際、メンバーの職能情報をWikiに保存しました。しかし、実務上ではプライバシーの問題もあるため、職能に関する情報をデータベースに格納し、そこから動的に情報を読み取らせる仕組みの検証も重要な課題です。現在想定される技術的課題として、データベース側のユーザーIDとBacklogのIDが異なることによるマッピング問題があり、この解決策の検討が必要となります。
Wikiに記載する内容の改善
現在のBacklog Wiki記載では、初期費用1200万円、運用費用50万円という数値が示されていますが、ユーザー側からは高額との評価を受けています。この事例は、提案内容における事実（数値データ）と担当者の所感（主観的意見）の両方が含まれた典型例といえます。
要約の品質向上においては、情報の適切な保存とナレッジの見直しという観点から、むしろ担当者の所感の方が重要な価値を持つ場合が多いです。現状のシステムは事実情報の要約に重点を置いていますが、今後はClaude側の要約手法に工夫を加え、主観的な意見や感想をより適切に抽出・整理する機能の強化が求められます。
宣伝
弊社ではデータ基盤やLLMのご相談や構築も可能ですので、お気軽にお問合せください。
また、中途採用やインターンの問い合わせもお待ちしています！
参考文献
[1]https://arxiv.org/pdf/2503.23278
[2]https://notion.notion.site/Notion-MCP-1d0efdeead058054a339ffe6b38649e1
[3]https://github.com/fleagne/backlog-mcp-server
[4]https://github.com/nulab/backlog-mcp-server
[5]https://dev.to/samchon/why-your-mcp-server-fails-how-to-make-100-successful-mcp-server-iem
Discussion