AI運用と役割分担

人間が主導権を握り、実装設計をコードレベルまで落とし込んだうえで、複数AIと相談しながら品質と実装を前に進めます。

人間が主導権を握る

NaifyはAIが最初にコードを書くことを前提にしません。主導権と最終責任は、エンジニアや設計責任者など、人間が持ちます。

現場の文脈、品質体制、利用者の実感は、最後まで人間が引き受ける必要があります。AIが書いた部分も含め、Naifyに入るコードは人間が内容を確認し、責任を持ちます。

エンジニアによるコード設計
APIの切り方、責務の置き方、例外の扱い、将来どこを差し替えやすくするかは、経験を伴う設計判断です。
フレームワーク利用者による意見
実際に使う側がどこで迷い、どこで壊しやすく、どこに説明不足を感じるかは、利用者の実感としてしか取れません。
現場経験者による品質管理体制の課題認識
どこでレビューが漏れやすいか、どの運用が破綻しやすいか、どのテストが本当に効くかは、現場で回した人間でないと見えにくいです。

「人間が実装境界と判断基準を先に決める。だからAIの書いたコードも人間がレビューしやすい。」

Naifyでいう設計は、言葉だけの要件整理ではありません。実装前に、少なくとも次を人間が具体化します。

Naifyがレビューしやすいのは、この具体化を前提にしているからです。設計を先に固めておくことで、AIが書いたコードでも、意図と違う実装に気づきやすくなります。

この粒度まで落として初めて、AIに対しても「指示通りか」を確認しやすくなります。 API /メソッド単位まで具体化されていれば、AIの提案や実装がその枠に沿っているかを、人間も別のAIも確認しやすいです。

人間が主導権を持ちますが、人間もAIも完璧ではありません。そのためNaifyでは、実装前に人間と複数のAIで相談し、設計と実装方針をすり合わせることを基本にしています。

この相談工程を省くと、人間の思い込みか、単独AIの思い込みに寄りやすいです。Naifyは、この事前相談そのものを品質運用の一部として扱います。見落としを実装前に減らせるため、手戻りの抑制にもつながります。

Naifyでは、AIは特に次の分野で力を発揮しやすいです。

これは他の用途を一律に否定する意味ではありません。まず強く使う中核領域がここだ、という意味です。

特に相性がよいのは、影響範囲調査、HTTPテスト、互換性チェック、PHPDoc /リファレンスのズレ確認、レビュー観点の棚卸しです。これらは本体コードを変更せずに、確認の量と精度を上げられる作業です。繰り返しの確認作業をAIが担うことで、人間は設計判断やレビューに時間を使えます。

AIが強い仕事
反復実行、差分比較、観点の列挙、レポート化、複数視点での相互レビュー。

ここでいう非破壊とは、本体コードや業務コードをAIが勝手に変更しない、追加しない、緩めないことを指します。

逆に、影響範囲調査、品質チェック、テストケース案の作成、失敗原因の調査、レポート整理のような作業は、非破壊の作業として積極的に活用しています。

人間の許可が必要なこと
本体コードの広範囲な変更、設計判断を含む修正、既存テストを緩める変更は、人間が明示的に許可した場合だけ行います。AIの作業で、既存のコードや動作が意図せず変わらないようにするための決まりです。

潜在バグ調査、定時分析、テストケース生成のような処理は、できれば別PCや別環境など、物理的に分けたサンドボックスで回す方がよいです。

これはAIが危険だからではなく、本体コードや作業環境への影響を分離し、品質チェックの系統を増やすためです。Naifyは、人間とAIが同じ一次情報を見る一方で、実行環境は必要に応じて分離します。

Naifyでは、AIが関与する場合でもテストを緩めません。テストケースは追記型を原則とし、既存テストの期待値を緩めて通すことはしない方針です。一度確認できた動作が、後の変更で気づかないうちに崩れることを防ぎやすくなります。

詳細な実行ポリシーは HTTP中心のテスト体制、品質の全体像は品質管理を参照してください。