はじめに
こんにちは、Musubi 機能開発チームの西村です。
湿度が高くなり、夏が近づいてきたと感じています。皆様いかがお過ごしでしょうか？
こちらのエントリでは、Musubi 開発が抱えていたボトルネックを AI フレンドリーにしてみたという内容をお届けします。
FigJam & Jira リファインメントの認知負荷
Musubi 機能開発チームでは、スプリントのリファインメントに FigJam（Figma 社のオンラインホワイトボード）と Jira を活用しています。
付箋をその場で追加・移動しながら議論でき、会議の流れをキャンバスにそのまま残せる点が気に入っています。
本記事用に作成した FigJam のサンプル（構成は実物に近づけています）。ストーリーごとにセクションを分け、タスク・仕様・設計を付箋で空間配置しています。
同じ構成を Jira に対応づけたときのサンプル（本記事用に作成）。ストーリーは Epic、タスクはサブタスクに対応し、SP や設計の詳細もそのまま引き継ぎます。
一方で、運用を続ける中で、以下の認知負荷が気になりました。
ボードを初見で読み解くコスト
FigJam のボードには、ストーリーに紐づくタスク付箋・ストーリーポイント（SP）マーカー・WIP スタンプが空間レイアウトで配置されています。
チームの読み方を知っている人にはすぐに把握できますが、参加頻度が低いメンバーや初見の人には、どのストーリーがどのフェーズにあるかを読み解く負担があります。FigJam と Jira の二重管理
リファインメント結果は最終的に Jira チケットへ反映するため、FigJam と Jira を二重に見る状態になります。
「このストーリーはすでに起票済みか」「どのタスクが対応するか」を確認するには、両ツールを手動で突き合わせるしかなく、関与頻度が低い人ほど確認コストがかさみがちです。Jira への起票作業負荷
FigJam で整理されたストーリーを Jira チケットに起こす際、ストーリーポイントやタスク一覧を手動で転記する作業が発生します。
件数が増えると繰り返し作業になりやすく、転記漏れのリスクも生まれます。
たまっていく情報を、AI に整理させる
FigJam の認知負荷は、情報がたまればたまるほど高くなっていきます。
ですが、 FigJam の解析と Jira チケットへの整理は AI を活用すれば自動化できると考え、 CLI ツールの figma-cli, jira-cli と、 Skill figma-analyze-story を試作しました。
CLI 作成にあたっての判断
Figma には公式の REST API があり、付箋やセクションの情報を取得できます。
ただ、多言語向けの公式 SDK はないので、API を直接呼ぶ形になります。
Figma 公式 MCP（dev mode MCP server）を使う選択肢もありましたが、FigJam を読むためだけに起動するのはひと手間でしたので、REST API を直接呼ぶ figma-cli を作成することで実現しました。
また、社内ツールは Node.js で書かれることが多いのですが、バイナリを配布してすぐ使えるので、 Rust で進めました。
この判断が正解かはまだ分かりませんが、まずはこの構成で進めています。
LLM の素の状態でどこまで判別できるか
作成当初は、 CLI で取得したデータをそのまま LLM に解釈させる方針で進めていました。
しかし、 LLM の解釈に任せた場合、構造化しておいた付箋やストーリーポイントの情報を読み解けないケースが頻発しました。
生データだけでの取り方が機能しやすいのは、「ノードに書かれたテキスト自体に意味が乗っているオブジェクト」だとわかってきました。
例えば、以下の事例が挙げられます。
フロー図（画面遷移・状態遷移など）
「ユーザー登録 → メール確認 → ログイン → マイページ」のような画面遷移図が、その典型です。
ノードとコネクタの関係がデータ上でも追いやすいため、 LLM は遷移の流れを箇条書きや文章にまとめられます。ドメイン設計・テーブル設計
サービスのドメインを整理した概念モデルや、テーブル名・カラム名・型を並べた簡易 ER 図のような設計図も、テキスト内容が揃っていれば LLM の読解で構造化できました。
座標の位置関係に依存せず、ノードの内容とコネクタの繋がりだけで意図が読み取れる図なら、専用の Skill を書かずとも CLI の出力を LLM に渡すだけで解釈できる傾向があります。
一方、「どのノードがどのグループに属するか」「マーカーやスタンプがどのタスクに対応するか」のように空間規約に意味が載ったオブジェクトでは、LLM の読解力だけでは安定しません。
AI に構造を渡す Skill を作る
そこで、空間規約を解釈する Skill を Python で用意しました。
たとえば「タスク付箋の右下に置かれたストーリーポイントマーカー」を見つける部分は、次のように座標で判定しています。
# タスク付箋の「右下」を、付箋サイズの半分を許容誤差として探索する search_x = task["x"] + task["width"] search_y = task["y"] + task["height"] tolerance_x = task["width"] * 0.5 tolerance_y = task["height"] * 0.5 # 許容範囲内のストーリーポイントマーカーを 1 つだけ対応づける（使った印は再利用しない） for i, marker in enumerate(markers): if i in used: continue if abs(marker["x"] - search_x) < tolerance_x and abs(marker["y"] - search_y) < tolerance_y: used.add(i) return marker["value"] return None # 見つからなければ WIP 扱い
タスク付箋の右下を、付箋サイズの半分を許容誤差として探索する。固定ピクセルにしないことで、付箋サイズが変わっても誤検出を抑えられる。
この Skill を通すと、以下のような出力が得られます。
### ストーリー１ SP:2 | [repository-one] タスク１ SP:3 | [repository-one] タスク２ WIP | [repository-two] タスク３ SP:1 | [repository-one] タスク４ → 4 タスク（SP 確定:3 / WIP:1） 合計: 1 ストーリー / 4 タスク（SP 確定:3 / WIP:1）
座標規約の解釈が必要な部分に専用ロジックを当てることで、 LLM も正確に読み解けるようになるという手応えがありました。
また、今回の CLI, Skill はすべて Claude Code に書かせ、レビューも CodeRabbit と Devin に回して作成しました。
手を入れずにマージした範囲でも、いまのところ大きな不具合なく使えているのは驚きです。
今後の展望
Jira 連携まで自動化し、最終的には FigJam to Jira sync のような形でまとめたいと考えています。
また、他にも残しておきたい情報を Confluence にまとめる Skill も用意できればと考えています。
おわりに
今回は、認知負荷の高いボード情報を誰でも読める形に整理するため、 AI 自身に CLI や Skill を作成させることで解決を試みているというお話でした。
Musubi チームでの開発に少しでも興味を持ってくださった方がいらっしゃれば嬉しいです！
カケハシでは、新しい技術を試しながら医療に貢献したいというエンジニアを募集しています！
