Kakusillとは｜要求整理から仕様化までの5つの働き
目次
要件定義の会議が終わり、AIに議事録を要約させる。数分後には、整った文章が出てくる。ここまでは速い。
ところが翌週、営業担当が話した例外条件は抜け、画面担当とAPI担当では「承認済み」の意味が違っていた。修正した仕様が、どの機能に影響するのかも追えない。文章はできたのに、開発へ渡せる仕様にはなっていない。
この溝を埋めるために開発しているのが、株式会社Atsumellの要求整理・要件定義支援プロダクト「Kakusill（カクシル）」である。文章を一度生成して終わるのではなく、会議メモや既存資料から業務の流れと不足論点を整理し、RFPや仕様へつなげていく。
Kakusillとは、要求整理を開発へつなぐ道具
Kakusillの公式紹介では、会議メモ・議事録・PDF・Excel・既存資料を、開発に渡せる業務フローと仕様へ整理すると説明している。要求整理から仕様化までを上流工程の一つの流れとして扱う。
ポイントは、AIに文章を書かせること自体ではない。現場の資料と会話から、誰が何をしているか、どこに課題があるか、次に何を決めるかを追える状態にすることだ。
一般的なチャットAIでも、要件定義書の初稿は作れる。だが、会話が変わるたびに全文を貼り直し、「前回との違い」や「関連する仕様」を人が説明していたら、管理負荷は残る。Kakusillは、要求・業務フロー・設計・テストのつながりを保ち、変更影響と合意の記録をレビューできる状態を目指している。
では、実際に何が変わるのか。公開中の製品紹介をもとに、本記事では要求整理から開発連携までを5つの働きに整理する。これは公式の機能区分ではなく、導入検討時に入出力を確認しやすくするための分類である。
要求整理から仕様化までを支える5つの働き
1．既存資料を要求のたたき台に変える
議事録、PDF、画像、Excel、PowerPoint、業務マニュアル、既存仕様書を取り込み、要求整理のたたき台へ変える。最初から専用フォーマットへ書き直すのではなく、すでにある資料から始められる。
古い資料を正しいものとして無条件に採用するわけではない。資料名、作成日、担当者を確認し、現場の運用と違う箇所は未決事項として残す。移行作業と要求確定を分けることが大切だ。
2．不足している論点をAIが聞き返す
業務担当者は、日常の例外をわざわざ要件として話さない。「月末だけ承認者が変わる」「返品時は別の台帳を見る」といった前提は、本人にとって当たり前だからだ。
Kakusillは、入力された内容から曖昧な要件や不足している前提を質問へ変える。代理申請、承認者不在、期限超過、差し戻し、取消後のデータまで確認すると、正常系だけでは見えなかった業務の境界が出てくる。
3．As-Is・To-Beの業務フローと課題を整理する
会議メモや現場資料から、誰が、何をきっかけに、どの順番で作業しているかを業務フローへ整理する。現状のAs-Isだけでなく、二重入力や承認待ちなどの課題を分け、To-Beを検討する材料にする。
フロー図をきれいに描くことが目的ではない。関係部門、入力、判断、 例外、成果物がつながり、企画やRFPで次に決める論点が見えることが重要だ。
4．要求・設計・テストをつなぎ、変更影響を追う
仕様変更の怖さは、一行を直すことではない。その一行に依存する画面、権限、通知、テストが見えないことだ。
Kakusillは、要求仕様から設計書、テスト仕様までのつながりを管理し、変更がどの工程・要件へ影響するかを確認できるようにする。決まった内容は合意として記録し、誰がいつ確定したかを後からたどれる。
AI要件定義は変更差分から始めるで紹介したように、変更前後を「入力・判断・出力・権限・停止条件」に分けると、影響の見落としを探しやすい。AIはレビュー材料を出し、最終判断と承認は人が担う。
5．RFP・仕様書・画面モック・開発連携へ展開する
整理した要求と業務フローは、社内説明だけで終わらせず、RFP、要件定義書、基本設計、画面モックアップへ展開する。開発チームへ渡す成果物を同じ文脈から作ることで、転記時の抜けを減らす。
さらに、コーディングエージェントがMCP経由で仕様を読み取れる状態にし、仕様書駆動開発へつなげる。Kakusillの役割はコードを無条件に完成させることではない。人が合意した要求と設計を、実装とテストが参照できる状態に保つことだ。
汎用チャットAIを単体で使う場合との違い
単発の企画書や小規模な検証では、汎用チャットAIへテンプレートと資料を渡すだけで足りる場面も多い。ここで比較するのは、プロジェクト機能や外部連携を組み合わせた利用形態ではなく、チャットを単体で使う場合である。
違いが出るのは、関係者と変更が増えたときである。
- 汎用チャットAIの単体利用は、初稿や論点の洗い出しが速い
- Kakusillは、要求・業務フロー・設計・テストのつながりと合意の記録を同じプロジェクトで扱う
- 単体利用の品質は、都度渡した文脈と質問者の力量に左右されやすい
- 構造化された環境では、チームで同じ仕様をレビューしやすい
要件定義支援ツールの比較記事でも、上流工程支援、文書作成・レビュー、文書管理、要件管理という得意領域の違いが整理されている。選定時は、トレーサビリティ、合意履歴、変更影響、権限管理の各軸を同じ完成済み案件で比較する。
Kakusillが向くのは、要件を聞き出す段階から、仕様同士 の整合、開発への受け渡しまでを同じ文脈で確認したいチームである。特に、顧客合意を設計書と受け入れ条件へ渡すSIerでは、発言の要約より関係者間の同じ理解を保てるかが判断軸になる。
導入前は「完成済み案件」で試す
デモを見るだけでは、AIが出した文章の美しさに評価が寄る。そこで、答えを知っている完成済み案件を一つ使う。
素材は、議事録、業務マニュアル、要件定義書、変更依頼、最終テスト結果の5点がよい。取り込んだ後は、5つの働きと評価指標を対応させる。
| 働き | 入力 | 期待する出力 | 評価指標 |
|---|---|---|---|
| 要求のたたき台 | 議事録・既存資料 | 決定事項と未決事項を分けた要求 | 人による修正件数、整理時間 |
| AIの聞き返し | 要求のたたき台 | 例外・権限・停止条件の質問 | 有効質問率、見落とした例外数 |
| As-Is・To-Be整理 | 業務マニュアル・会議メモ | 担当、判断、課題を含む業務フロー | 現場レビューの指摘数 |
| 変更影響の追跡 | 変更依頼・既存仕様 | 影響する要求・設計・テストの一覧 | 調査時間、影響漏れ数 |
| 開発連携 | 合意済み要求・設計 | RFP・仕様書・モック等の成果物 | 開発側の追加質問件数と内容が従来より減ったか |
正解を知っている案件なら、見落としも誤検知も判断できる。測るのは生成文字数ではない。会議後の整理時間、レビュー指摘数、開発側からの確認回数、変更時の調査時間だ。
同時に、製品デモでは確認できない運用条件を質問する。顧客、社内PM、外部パートナーで閲覧範囲をどう分けるのか。AIへの入力と生成結果をどこまで記録するのか。保持期間や削除手順はどうするのか。これらは公開情報だけで断定せず、自社のセキュリティ条件と照合する。AI要件定義ツールの選び方に比較軸をまとめている。
仕様書は「完成させる文書」から「育てるデータ」へ
AIで仕様書を作成する価値は、初稿を速く出すことだけではない。抜けた前提を質問に変え、言葉の意味を揃え、関連する仕様をたどり、次の開発へ同じ文脈を渡す。この一連の流れが、会議後の整理時間や追加質問、変更調査をどれだけ減らすかで評価する。
この循環を一つの環境で扱うのが、要求整理・要件定義支援プロダクトの役割である。あなたのチームで仕様が止まっているのは、要求整理、レビュー、合意、引き渡しのどこだろうか。完成済み案件で一度たどると、必要な働きが見えやすい。
株式会社Atsumellでは、既存の要件定義プロセスを可視化し、Kakusillを使った検証設計からAI開発への接続まで支援している。自社の資料でどこまで構造化できるか確かめたい場合は、お問い合わせフォームから相談してほしい。
