仕様は消え、テストは足りない──AIを阻む壁の正体
──過去の講演で「レガシーコードとAIツールの相性は良くない」という話もされていました。基幹システムへのAI活用を阻んでいるレガシーの壁とはどのようなものがありますか？
北村圭氏（以下、北村）：まず「仕様の消失」です。20年来の基幹システムには、仕様の経緯や要求・要件がどこにも残っていない部分があります。AIに任せても「何を正として実装するか」というコンテキストを渡せないので、暗黙知のまま放置されているものはAIにも伝わらず、そのままだとアウトプットが的外れになります。
次が「テスト不足」です。関数レベルのユニットテストは多くありますが、機能全体のワークフローを担保するインテグレーションテストやE2Eテストが致命的に不足しています。AIがコードを生成しても、テストができないのでマージの判断ができないという壁です。
また、GitHubのエコシステムに乗れない独自CIが動いていて、AIが良かれと思ってやったことが運用に合わず動かないケースも散見されます。文字コードもUTF-8を前提とするAIに対して、既存コードはShift-JISが残っている部分があり、モノタロウでも一括変換の取り組みが進んでいる最中です。さらに、テスト仕様書がスプレッドシートの手書き手順だったり、デプロイ後に手動で検証するプロセスが残っていたりと、AI readyになっていない部分がまだ多い状況です。
──壁を越えるためにどんなアプローチを取っていますか？
北村：AIで全体に適用できるものは一気にやってしまうのが1つの手段です。文字コードの問題のように、一括で対応してしまうのが有効です。
次に、テストの整備は今まさにチャレンジしているところなのですが、「レガシーだからテストが作りにくい」というのは実は思い込みだということがわかってきました。インテグレーションテストやE2Eテストを、AIに任せて作ってしまうという方法です。人間が作ったら現実的でないような量のテストも、AIなら大量に作ることができます。テストを拡充さえすれば、中身の実装をAIに任せ切ることができます。
また、モダナイゼーションでは新旧比較テストが重要になります。新旧の環境を整備して、差異を分類し、1つ1つのイシューに対してAIに修正してもらうという、連続したループをAIに任せてしまえることがわかってきました。
ハーネスエンジニアリングをモダナイゼーションに活用
──北村さんは基幹システムにハーネスエンジニアリングを活用されていると伺いました。北村さんは、ハーネスエンジニアリングをどのようなものと考え、具体的にどう整えていますか？
北村：ハーネスという言葉は人によって定義が異なり、口にするのは難しいのですが、私は「AIに仕事をさせるための実行レールと制約」という理解をしています。
まず開発環境と分離された、AIが動くためのコンテナ（Pod）を社内の独自基盤として用意しています。その中でClaude CodeやCodexには自由に動いてもらいます。Podは開発環境のネットワークに閉じているので、本番環境への意図しないアクセスも防げます。
次に「エージェントスキル」による制約です。AIに仕事を任せるにあたって、長いタスクはタスクを分割する必要があります。1つ1つのタスクをある程度抽象化して、タスクからタスクへパイプラインで繋いでいく。そのパイプライン全体が機能しているかを監視・改善することまで自動化させることが重要です。
具体的には、エージェント自身が計画を立て、テストを実行し、その結果を分類し、複数サブエージェントによる「敵対的レビュー」で厳密に検証する。PRも自動で出し、それに対してもセルフレビューするというループを回しています。この比較検証の仕組みを、調査や長いタスクにも適用しているのが今整えているハーネスです。
──ハーネスエンジニアリングの成果と限界はどのようなものですか？
北村：ハーネスエンジニアリングは突破口の1つではありますが、銀の弾丸ではないという理解です。ハーネスを使って長時間安全に動かすことはできても、「何を修正してどのテストで担保するか」が明確でないと、長時間稼働しながらも失敗し続けるという事態が実際に起きました。AIは適切な情報がないと自分が間違っていることに気づけないため、コンテキストとテストによる保護が、ハーネスとセットで必要になります。
新規で構築するグリーンフィールドについては、実際に生産性が上がり、他案件の都合で数カ月遅れる予定だった開発を完全に取り戻しました。一方、既存システム部分であるブラウンフィールドにAIを適用しようとすると、文脈の整備が整っていないという問題があります。テストが弱い領域は進みが悪いというのが正直なところで、そこが次の課題になっています。
