要件では
操作者と更新対象ユーザーの双方が、許可された権限を持つ場合に限り更新できる。
実装では
操作者の権限だけを確認し、更新対象ユーザーの権限を取得する処理は見つからない。
UserController.php:228–246説明: 運用担当者またはシステム管理者であれば、対象ユーザーの権限に関係なくフラグを変更できる挙動になる可能性があります。
⌄ 技術的な根拠を表示
要件と実装の整合性を、PR単位で確認
その実装は、
合意した要件を
満たしていますか。
Joshは、GitHubの変更と要件を突き合わせ、レビューで確認すべき差分をコードの根拠とともに示します。 開発チームは、指摘を確定するか、誤検出として棄却するか、その場で判断できます。
登録だけで利用契約は発生しません。募集開始時にご連絡します。
要件と実装の整合性最新の検証: 完了（2026/8/17 2:19:53） ／ 対象 1件
▶ 要件別の横断状況（補助表示）
指摘一覧
1/9件 レビュー済み
指摘あり高 0中 9低 0要件 ≠ 実装 3実装の欠け 6
SPEC-0005乖離の疑い未レビューを順に確認
PRだけでは分からない変更理由まで確認要件本文GitHubの差分変更履歴テスト結果
レビューの現場で
仕様を探すところから、レビューが始まっていませんか。
コードは読めても、なぜその変更になったのかはPRだけでは分かりません。確認先を知っている人がレビューに入れないと、要件の抜けはそのまま通ります。
Reviewer「このPRの仕様、どこにまとまってる？」
Developer「最初は設計書です。途中の変更はSlackとPRにあります」
PM「PRにしかない要件まで、レビュアー以外に見えてる？」
Joshで確認できること
差分を見つけたあと、根拠を開いて判断できる。
Joshは結論を代行しません。要件と実装を並べ、関連するコードと変更履歴を示します。最後に対応を決めるのは、内容を確認した開発チームです。
要件 ≠ 実装対象ユーザーの権限を確認せずフラグ更新を許可する可能性
未レビュー 要件では
操作者と更新対象ユーザーの双方が、許可された権限を持つ場合に限り更新できる。
説明: 要件で求める権限条件と実装の処理に差異がある可能性があります。
技術的な根拠を表示
タイムラインREQ-0045 権限制御
12件- ✓要件本文を確定版
権限条件と受入条件を更新
- ↗リリースへ紐付け
REL-2026-08 認証基盤更新
- ◫要件実装検証を実行
乖離の疑いを1件検出
変更と影響このリリースで変わる範囲と、確認が必要な差分。
判定対象の要件12件
実装との乖離1件要確認
部分確認・確認できず2件要確認
確認未実施0件
未カバー要件1件要確認
未レビュー3件要確認
0件は問題がないことではなく、現在取得済みの検証範囲における集計です。
要件 ≠ 実装
対象ユーザーの権限を確認せずフラグ更新を許可する可能性findingの対応を決める
未レビュー要件では
操作者と対象ユーザーの権限を確認する。
実装では
操作者の権限だけを確認している。
比較する要件は、どう用意する？
その1行から、PRと照合できる要件へ。
要望や資料を、現行システムの情報と照らして評価。未確定の条件を論点として抽出し、回答候補と判断材料を提示します。チームの決定を対象範囲・仕様・受入条件へ反映し、確定した要件をPRとの照合に使います。
手元の要望や資料を起点に要望アセスメントLinearJiraConfluence
たとえば、こんな1行の依頼から
「申請の承認待ちを、
必要に応じて通知できない？」誰に、いつ、どう通知するかは、まだ未定。
申請の承認待ち通知
OI-002申請から、どの時点で通知しますか？
採用対象要件SPEC-001申請の承認待ち通知
決めること業務責任者の判断
承認待ち通知を実行するタイミング
未決の場合: 通知処理の実行条件と、通知すべきケースのテスト条件を確定できない
回答候補
申請直後に通知する
トレードオフ: 承認担当者がすぐに気づけるが、すべての申請で通知が発生する
一定時間、承認待ちなら通知する
トレードオフ: 承認が滞っている申請に絞れるが、通知までの時間を決める必要がある
採用した回答候補その他（自由入力）
トレードオフ: 業務に合わせた条件を定義できるが、実行時点と例外を明示する必要がある
Joshの推奨: 承認の滞留を防ぐことが目的なら、一定時間、承認待ちの場合に通知する。通常処理中の申請への通知を抑えられる。
論点
申請から、どの時点で通知しますか？
背景
依頼の「必要に応じて」では、通知の実行条件が未定義です。通知対象者と通知手段は別の論点として確認し、この論点では通知時点と例外条件を決めます。
決定内容
申請から24時間後に判定し、承認待ちなら通知する。承認済みなら通知しない。
OI-002 通知のタイミング
採用申請の承認待ち通知
確定決定した内容を要求単位（REQ）に分け、それぞれに受け入れ条件（AC）を紐づけます。
要求単位と受け入れ条件の対応
| 要求単位 | 区分 | 状態 | 受け入れ条件 | 出典 |
|---|---|---|---|---|
REQ-1申請から24時間後、承認待ちの場合に承認担当者へメールを1回送信する。 | 挙動 | 確定 | AC-1 AC-2 | OI-001 OI-002 OI-003 |
REQ-2アプリ内通知と、同じ申請への再通知は今回の対象外とする。 | 対象外 | 確定 | AC-3 | OI-003 |
受け入れ条件
AC-124時間後の判定時に承認済みなら、通知メールを送信しない。
REQ-1AC-224時間後も承認待ちなら、承認担当者へメールを1回送信する。
REQ-1AC-3アプリ内通知と、同じ申請への再通知を行わない。
REQ-2承認待ち通知
計画中- 1
- 2
- 3
- 4
対象要件と対象PR対象要件 1件・対象PR 1件
対象要件SPEC-001 申請の承認待ち通知
対象PR#128 承認待ち通知を追加
整合性テストリリース判断
整合性
実装 ⇔ 要件の整合性を確認
未実行仕様書と比較
指摘一覧
対象要件とPRを指定して、検証を実行。
確定したREQ・ACと変更コードを照合し、確認すべき差分を表示します。
表示:指摘あり要件 ≠ 実装 1
要件 ≠ 実装承認済みの申請にも通知する可能性未レビュー
要件では:
24時間後の判定時に承認済みなら、通知メールを送信しない。（AC-1）
実装では:
24時間の経過だけを判定し、承認済みかどうかを確認せず送信している。
説明: 要件の通知条件と実装の処理に差異がある可能性があります。根拠を確認し、対応を判断します。
技術的な根拠を表示
− 申請から24時間の経過を判定し、承認担当者へメールを送信している。送信前に承認状態を確認する分岐がない。
− 作成から24時間以上経過した未通知の申請を取得している。取得条件に承認待ちへの絞り込みがない。
判断根拠: PR #128の変更差分から通知処理と定期実行処理を確認。対象申請の取得条件と送信直前の分岐を照合したところ、いずれも承認状態を確認していない。AC-1で求める、承認済みの場合は通知しないという条件が実装されていない可能性がある。
決めた要件を、実装の確認基準に。
論点の決定から、要件の確定、PRとの照合までをつなぎます。
いつもの開発フローに追加
リポジトリを接続したら、確認結果をレビューに戻す。
- 接続対象のGitHubリポジトリと要件資料を指定
案件ごとに解析対象を分け、必要な範囲だけを読み込みます。
- 検証変更されたコードと、関係する要件を比較
実装の欠け、要件との違い、確認できなかった箇所を指摘一覧にします。
- 判断コードの行番号まで開いて対応を決める
修正する、要件を直す、差異を許容する。理由とともに判断を残せます。
導入前に確認できること
コードと要件資料の取り扱い
接続方式、取得範囲、保存方針はトライアル前に確認します。案件や顧客の条件に合わせて利用範囲を決められます。
- 解析範囲
- 対象リポジトリと解析範囲を案件ごとに指定
- 権限
- 閲覧、編集、管理を役割ごとに設定
- 操作履歴
- ユーザーごとの操作を監査ログに記録
- LLM
- OpenAI、Anthropic、Googleの自社APIキーに対応
- 保存・AI利用
- 詳細条件をトライアル前に個別説明
先行利用のご案内
自社のPRと要件で、検証してみませんか。
先行利用や検証協力の募集開始時にご連絡します。フォームでは、担当領域と現在のレビュー課題を伺います。