検証はシニアエンジニアのAI優位性
AIはコード生成を安くしますが、信頼できる本番変更には検証、判断、責任が必要です。
AIはコードを作りやすくします。ソフトウェアを信頼しやすくするわけではありません。この違いは、シニアエンジニアにとって重要なキャリアシグナルになっています。誤った本番変更のコストは、下書きのコストが下がっても下がりません。
Stack Overflowの2025 Developer Surveyはこの緊張を示しています。AIツールの正確性を信頼する人より、不信を持つ人の方が多いです。46%が不信、33%が信頼、強く信頼する人はごく少数です。経験を積んだ開発者は、公開した変更の責任を持つため慎重です。
仕事は証明へ移る
モデルはmigration、Kubernetes manifest、Solidity helper、monitoring script、GitHub Action、API endpointを生成できます。シニアの問いは、その変更が実システムを尊重しているかです。auth境界、race condition、gas前提、chain挙動、依存version、rollback、observabilityを確認します。
検証は最後の丁寧なreview手順では足りません。AI-native engineeringでは、検証がworkflow設計の一部です。Agentは下書きし、比較できます。システムが検証し、責任や不可逆性がある場所では人間が承認します。
証拠の階段を作る
強いAI workflowは、reviewerに生成された答えだけを渡しません。source context、model assumptions、generated change、automated checks、human review、post-change monitoringという証拠の段階を通ります。各段階は信頼を上げるか、workflowを止めるべきです。
AIの誤りは、しばしば一貫して見えます。migrationは構文を保ちながらretention ruleを壊せます。runbook更新は有用に見えて、実際に機能する唯一のescalation pathを消すことがあります。transaction説明は流暢でも、誤ったtarget addressを隠していることがあります。
- source context: Agentが使ったfiles、logs、tickets、docs。
- assumptions: modelが推測したが証明できない制約。
- checks: tests、simulation、static analysis、policy gate。
- approval: 名前付きreviewerと、その人が受け入れた証拠。
- monitoring: release後に結果を確認または否定するsignal。
強い検証の中身
- 静的解析、type check、lintで基本的な正しさを見る。
- 実際のユーザーまたはオペレーターの経路に結びついたunit、integration、E2E test。
- tool、secret、本番アクセスのsecurity scanとpermission review。
- deploy、Safe transaction、contract interaction、高影響config変更前のsimulation。
- 不可逆、高コスト、security-sensitiveな操作への人間承認。
- post-deploy monitoring、rollback path、何が起きたかを示すaudit log。
Blockchainではさらに厳しくする
on-chainシステムは弱い検証を許しません。生成されたhelperが表面的なtestに通ってもaccounting前提を壊すことがあります。もっともらしいSafe transactionが誤ったmoduleを指すこともあります。monitoring scriptが重要なsignalを逃すこともあります。
そのためAIは、操作より先に証拠を準備するべきです。diff、simulation、event trace、runbook状態、signer contextを集めます。実行はdeterministic checkと責任あるreviewの後です。
実用チェックリスト
- AIは何を変更し、どの前提を置いたか。
- どの本番システム、権限、ユーザー経路に影響するか。
- どのtestまたはsimulationが文脈内で証明するか。
- どのreviewerが承認し、何の証跡が必要か。
- 事後に操作経路を示すlogはどれか。
- 出力が誤った場合のrollbackまたはmanual overrideは何か。
速い下書きは、間違った下書きを捕まえる検証経路がある場合にだけ有用です。
参考資料
Nexuain の実務上の示唆
検証のないAI速度は強みではなく、運用リスクです。秘密鍵へのアクセス、chainIdの不一致、失敗したシミュレーション、未承認のSafeモジュールやガード変更、人間承認なしの資金移動はブロックします。
