shirusu の思想

中核: AI作業を通すだけで、必要なガードと証跡が揃う

shirusu は、複数のAIを使うエンジニアリング作業へ、安全な既定値、品質レビュー、
人間承認の境界、機械可読な証跡を追加するローカル実行ツールである。

AI作業を shirusu 経由にするだけで、必要なガードと証跡が自動で揃う。

エンジニアに、依頼のたびに法令、社内規程、AIサービスのリスクを読み解かせない。
利用者は普段どおり作業を依頼し、shirusu が定義済みの安全ベースラインを決定的な
コードと設定で適用する。確認できなかったことと、人間が最後に判断すべきことだけを
短く、行動できる形で返す。

安全のためにAI活用を一律禁止するのでも、便利さのために境界をなくすのでもない。
安全な既定値で始め、必要な箇所だけ人間へ判断を戻し、その経緯を自動で残す。

定義済みの安全を自動化し、法的判断は捏造しない

shirusu が提供するのは「法令への完全準拠」ではない。定義済みルールに基づく安全確認と、
後から検証できる判断・作業証跡である。

shirusu は次を担う。

一方、次を保証したとは言わない。

「問題なし」は、定義済みcheckが通ったことを意味する。法的準拠やリスクゼロを意味しない。
製品として保証する境界の詳細は Product Contract v1 を正とする。

実行状態と安全判定を分ける

作業が完了したかと、安全上の確認が必要かは別の軸である。

種別通常の表現意味
実行状態実行中 / 完了 / 要確認 / 失敗作業プロセスがどう終わったか
安全判定問題なし / 確認あり / 停止判定 / 判定なし定義済みルールが何を検出したか
実際の影響実行後に検出 / 実行前に停止対象処理を本当に止めたか

重大な事後検出である「停止判定」と、処理を実際に防止した「実行前に停止」を混同しない。
内部の verdict=block だけを見て停止済みとは表示せず、実停止の証拠がある場合だけ
「実行前に停止」と表現する。過去形式で判定情報がないrunも、問題なしとは推定しない。

説明できないAI活用は、仕事では使い続けられない

AIの出力が良いかどうかだけでは、実務でAIを使い続けることはできない。
取引先に、経理に、監査に、そして未来の自分に、こう説明できる必要がある。

shirusu は「AIをうまく使うためのツール」であると同時に、
AI活用の説明責任 (accountability) を支える仕組み である。
速いだけのAI活用ではなく、後から確認し、説明し、改善できるAI活用のための道具。

AI を直接賢くするのではなく、
AI の使い方・順番・レビュー・ログを賢くする。

「なぜそのAIか」は、宣言 × 過程 × 証拠 で説明する

モデルは日々更新される。だから「このモデルはこういう性格だ」という
人間の感想をメンテし続ける設計は必ず腐る。shirusu は「なぜ」を
3つの源泉から機械的に導出する。

源泉内容性質担い手
① 宣言このロール (仕事) には何が必要か — required_capabilities安定 (仕事が変わらない限り不変)人間が書く
② 過程この run で候補がどう評価され、何が除外され、何が採用されたか揮発fallbacks[] に自動記録
③ 証拠このロール×このモデルの実績 (score・リトライ率・所要時間)変動runs/ から自動集計

decision-log.md の「モデル選定理由」はこの3つの合成である。
モデルがアップデートされれば③が勝手に変わり、理由も勝手に最新化される。
人間が書き続けるのは①だけ — それは業務が変わらない限り変わらない。

例外として人間が書き残す価値があるのは 契約・規約上の制約
(「このモデルは規約上顧客データ不可」等) のみ。これは品質評ではなく
ルールなので腐りにくい。書く場合は verified_at 日付をつける。

成果物の階層

各 run は成果物と同時に「判断の記録」を残す。

ファイル役割メタファ
final.md成果物または write mode の作業報告納品物・作業報告
decision-log.mdどう判断し、どう処理したか判断・作業証跡
approval-required.md人間が何を確認・承認すべきか稟議書
run-summary.json全判断の機械可読ログ台帳

実行の境界ではなく、確定の境界を人間に残す

AI は、明示的に承認された write mode では working tree のファイル変更と、そのための
コマンド実行まで担う。人間が全差分を手で適用することを安全性の前提にはしない。
一方、以下の確定は人間の手に残す。

自律性を上げる拡張 (動的オーケストレーション・並列選抜・実績ベース選定) を
積むときも、この確定の境界は変えない。write mode の変更は Git 証跡を残し、
コミット・送信・公開の前に人間が差分を確認する。

データ境界 (scope) はユーザーの主権

どの情報を外部AIに渡すかは、モデルの都合ではなくユーザーが決める。

「便利だから全部読ませる」をデフォルトにしない。
逆に「怖いから何も使えない」にもしない。境界を選べて、記録に残ることが要点。

小さく始めて、証拠で育てる

深くやるべき仕事を見極めて、ちゃんと深くやる。すべての依頼を重くするのではなく、
公開・納品する成果物など明示的に品質が必要な仕事では、勝利条件を先に定義し、
生成物を別の視点で壊し、修正と再採点まで行った工程そのものを KOKUIN に残す。