NEW SERVICE ── 新サービス
Ojou
オ ジ ュ ー
自社保有AIによる、定額のドキュメント／コード整合性チェック
サブスクでもAPIでもない。ソブリンAIだからできる、
長大な仕様書とソースを"読み切る"品質保証。
なぜ他ではできないのか
「AIに全部読ませて
チェックさせたい」
── その壁は、2つあります
壁 01
サブスクAIでは、できない
月額のチャットAIに大規模な仕様書とソースを丸ごと渡そうとすると、必ずどこかで頭打ちになります。
- ✗トークン制限で、途中までしか読めない
- ✗コンテキスト長の制限で、全体を一度に見渡せない
- ✗無能なサブエージェントへ“丸投げ”され、精度が崩れる
壁 02
API直利用は、高額すぎる
では従量課金のAPIで読み切らせれば？ ── 大規模案件では、請求が青天井になります。
一説には、その請求が
4億円規模
──に達したという逸話が囁かれるほど
※ あくまで業界で語られる逸話です。金額の真偽はさておき、従量課金は「読ませるほど際限なく高くつく」という構造そのものが問題です。
だから ── 自社で持つAIに、頼む。
とろたくのソブリンAI基盤なら、トークン課金なし・長大コンテキストを一気に読み切り、定額でチェックできます。
サービス内容
Ojou が読み切る、3つのチェック
人手では見落とす“ドキュメントとコードの食い違い”を、AIが端から端まで突き合わせます。
CHECK 01
ドキュメント
整合性チェック
整合性チェック
文書 VS 文書
設計書・仕様書どうしの矛盾を洗い出す
- ●テスト仕様書 VS 基本設計書 等の突き合わせ
- ●設計書どうしの矛盾点・記述のズレの洗い出し
- ●「どちらが正しいのか分からない」箇所をリスト化
CHECK 02
ソースコード・
ドキュメント
整合性チェック
ドキュメント
整合性チェック
文書 VS コード
「仕様書どおりに作られているか」を突き合わせる
- ●基本設計書 VS ソースコード の整合性
- ●テスト仕様書（結果） VS ソースコード の整合性
- ●実装と文書の乖離、未実装・仕様外実装の検出
CHECK 03
ASIS / TOBE
機能過不足
チェック
機能過不足
チェック
現行 VS 刷新
現行（ASIS）と刷新後（TOBE）の機能差を可視化
- ●ASIS / TOBE 間の機能差異の洗い出し
- ●移行・刷新で抜け落ちる機能（漏れ）の判定
- ●過剰機能・不足機能の一覧化で、要件の穴を塞ぐ
