「AIにマイクロマネジメントをするな」――大阪ガスが構築した、データ分析・開発の様々な工程を自動化する統合開発基盤

止まってはならないシステムを抱える大阪ガスが、データ分析や開発にかかる期間と費用を大幅に圧縮する統合開発基盤を作り上げた。鍵となったのは、AIを“部下”として扱う組織設計と、ドキュメントから図面まで機械可読のフォーマットに置き換える割り切りだ。データ分析から出発し、システム開発の世界にも手を広げて全方位DXをリードしてきた同社DX企画部AI推進チームの國政 秀太郎氏に、その現在地を聞いた。

「マイクロマネジメントをやめよう」――開発期間の大幅圧縮の裏側

――重要インフラを担う企業ならではの制約のもとで、AIをどう位置づけてきたのでしょうか。

品質に求められるレベルが、非常に高いんです。単体テスト、結合テスト、受け入れテスト――何千、何万というテストケースを、以前は手動でExcel管理し、人海戦術とコストをかけて品質を担保してきました。ここに対する熱量が高い。リリース後に直せばいい、という発想を取れないプロジェクトが多いんです。

当社は、海外のエネルギービジネスの開拓からガス製造や発電、お客さまへの小売まで、エネルギー事業を一貫して手掛けています。事業領域が広い分、プロジェクトのテーマも次々に出てくる。そのたびにベンダーへ発注していては追いつきません。一方で、重要インフラを担う以上、品質基準を下げることもできない。開発の頭からお尻までをオートメーション化しながら、品質も担保してスピードも上げる。この難題を乗り越えることが、当社のような企業に求められていると考えています。

――そのうえで、開発期間と費用が大幅削減になったと伺いました。数字の裏で、現場では何が起きていたのでしょうか。

2025年の春が転換点でした。Claudeのように、チャットで指示を出すだけでソースコードを一気に書いてくれるAIが登場し、「これはいける」と感じたんです。GeminiとClaudeを、リリースから1週間以内にチーム内の開発環境へ導入しました。ミッションクリティカルなプロジェクトにも、思い切って投入したんです。「ここまでコードが書けるなら、AIにかなり任せられる。人間は最後の門番になればいい」――そんなマインドチェンジが、2025年の夏頃から現場で起こり始めました。

結果として、開発期間と費用がかなり圧縮されました。率直にいえば、コーダーやテスターという職種が担っていた領域は、ほぼゼロになったんです。設計書をプログラミング言語へ翻訳するコーディング作業を、当チームではもう人間がおこなっていません。ClaudeやGeminiがコードを書き、自動テストまで済ませた結果を、設計者やPMが最終確認するだけです。

――AIが書いたコードをどこまで人間がレビューすべきか、ここは悩ましいポイントです。

そこで私の開発チーム内に呼びかけたのが、「マイクロマネジメントをやめよう」ということでした。コードの中身を人間が1行ずつ読まなくても成立する仕組みを、3段構えで整えています。まず、機械による静的解析でフォーマットやルールをチェックする。次に、テストコードがカバレッジを十分に満たしているかを確認する。ミッションクリティカルなシステムでは、ほぼ100%を要求します。そのうえで、テストケースが仕様書通りになっているかを最後に人間が確認する。この3つをクリアできていれば、中のコードを細かくレビューしてもしなくても結果は変わらない。だから、そこに時間を使わなくていいんです。

2025年の秋頃までは、正直、メンバーにも抵抗はありました。細かいところまでレビューコメントを書き込む人もいたんです。ただ、そこに対しては「それはマイクロマネジメントではないか」と伝えてきました。

相手がAIであれ人であれ、細かく管理しすぎるのは違うと思っています。人間なら疲弊して辞めてしまいますし、AI相手でも、重要な指標をクリアしているなら、そこまで踏み込む必要はない。頭では理解していても、感情としてはまだ納得しきれていない――そんな温度感は年明け頃まで残っていました。「このテストコードの書き方は少し気持ち悪い」と言う人もいました。ただ、その“気持ち悪さ”を修正するのも、結局はAIなんです。もう人間が細かく手を入れる世界ではなくなりつつあります。

パワポを捨て、AIエージェントを「ハーネス」で束ねる

――開発の上流工程では、どんな変化が起きたのでしょうか。

PowerPointとExcelを、ほとんど使わなくなりました。当社ではNotionを基盤にしていて、裏側はMarkdown、JSON、YAMLです。アーキテクチャ図やシステム図も、以前のPowerPoint／Excel中心の運用から、Mermaidやdraw.ioベースへ切り替えています。MCP経由でClaude CodeやGemini CLIがNotionを直接読み込み、そのまま処理できるようになりました。

もちろん、「人間にはPowerPointのほうが見やすい」という声もあります。ですが、そこは「人間が合わせるべきだ」とメンバーには伝えています。多少読みにくくても理解はできるわけですし、本質を見るべきでしょう、と。人間の組織でもPowerPointの見やすさや体裁ばかりを部下に指摘し、中身については大して触れない上司はあまり歓迎されないじゃないですか。AIに対しても同じで、細かな見た目より、本質的な情報を重視してほしいんです。今でもExcelで資料を提出してくる人はいますが、その場合は差し戻しています。

一方で、経営層やビジネス部門向けには、AIが作成したドキュメントやソースコードを、人間が読みやすい形に変換するAIを別で用意しています。インフラ構成図もTerraformですべてソースコード化しているので、そこから画像を生成すればそのままアーキテクチャ図が即座に生成されます。これをビジネス部門へ送ると、その早さに驚かれることもあります。人間向けのリバースエンジニアリングのようなものですね。

――「エージェントハーネス」という仕組みを早期に導入していると伺いました。

以前は、チャットベースで指示を出し、AIにコードを書かせることがメインでした。現在は、Claude CodeやGemini CLIにソースコード生成からテスト実行までを担わせ、その工程を順番に流すワークフローを構築しています。エージェントの実行工程そのものは決定論的に動き、AIは非決定論的に動く。このハイブリッドを進めることで堅牢性と柔軟性を両立できています。

ユースケースごとに、調査エージェント、設計エージェント、実装エージェントを配置し、それぞれに「このフォーマットで出力する」というフェーズゲートを設けています。基準を満たさなければ差し戻し、通過すれば次へ進む。考え方としては組織運営に近いですね。Aさんがこの仕事を担当し、決められた形式でアウトプットし、次はBさんへ引き継ぐ。引き継ぐ相手はプログラムなので、作業の抜け漏れが起きません。

きっかけは、2025年秋のClaude Haiku 4.5の登場でした。安価でありながら、プログラミング性能が十分高かった。ところが、その一方で、エンジニアによって出力の質に大きな差が出たんです。SonnetやOpusは性能が高く、多少指示が雑でも適切に補完してくれていたため、差が見えなかった。しかしHaikuを使わせた途端、その差が顕著に表れ、急に「上司力」が問われるようになったんです。

そこで、人材育成だけで解決するのではなく、仕組みとしてルール化する方向に舵を切りました。スキル書やワークフローを整備すれば、あとはシンプルな指示で何時間かかってもワークフローが自律的に進む。その過程はある程度仕組化されているので属人性も少ない。人間は上司として、「問題ないか」「テストは通っているか」と最後に承認するだけです。将来的には、チャットによるやり取りすら不要になるかもしれません。

「門番」と「プラットフォームエンジニア」、そしてジュニアを"培養"する

――人間のエンジニアに残される仕事、求められる能力や育成の形は、どう変わっていくのでしょうか。

大きく3つあると考えています。

1つ目が「門番」です。各開発フェーズの最後で、人間が意思決定をする役割ですね。最終的な責任は人間しか負えません。説明責任もありますし、AIが問題を起こしたときに対応するのも人間です。経験の浅いエンジニアには難しい役割だからこそ、実践を通じて経験を積む必要があります。

2つ目が、プラットフォームエンジニアリングです。AIがハーネスも含めて、自社環境に合わせて正しく、安全に動く仕組みを整備できる人材です。オフィス環境や総務機能を整えて社員が働きやすくなるのと同じで、AIにとっての“働く環境”を整える役割がプラットフォームエンジニアリングなんです。

3つ目がFDE――フォワード・デプロイド・エンジニアです。これも結局は要件定義で、ビジネス側の暗黙知をAIにもわかるように形式知化・言語化し、適切な指示へ落とし込めるかが重要になります。

そして育成の考え方も変えようと模索しています。例えば、仮想プロジェクトをジュニアメンバーに最初から最後まで短期間で複数個回させるなど。社内の小さな課題を解決するシステムを、あえてゼロからたくさん作らせるんです。

現在の環境では、小さなSaaS開発であれば1週間程度で一通り回せます。従来のOJTでは、半年から1年かけてようやく1案件経験できるかどうかでした。しかし1週間単位で回せるのであれば、3カ月で十数回の経験を積ませることができる。ベテランが何年もかけて到達した経験を、大幅に短縮できる計算です。

一方で、コードレビューはあえて人間に担当させます。「なぜこのバグが起きたのか」を考えさせ、失敗から学ばせるためです。これからは、コードを書く能力以上に、問題を発見し、原因を見抜く力――デバッグ能力の重要性が増していくと思います。

縁の下のプラットフォームエンジニアリングを、もっと評価してほしい

――最後に、AI要件定義サミット2026では、どこに注目して聞いてほしいですか。

注目していただきたいのは、当社のように、一見するとITから程遠く見える会社でも、内製型で開発の頭からお尻までを自動化するプラットフォームを構築できた、という事実です。特定の誰かがすごかった、というわけではありません。「基盤」をしっかり整える、仕組み化する、ハーネスで支える――その積み重ねの結果です。当社のスピリッツである「お客さま起点、誠心誠意・使命感、進取の気性」という姿勢が、そのまま基盤づくりにも現れていると思います。

一昔前には注目されなかったプラットフォームエンジニアリングの重要性に、当社は一足早く気づき、注力してきました。だからこそ、Claude CodeやGemini CLIが登場した時にすぐに現場へ組み込むことができたんです。

どうしても、大規模プロジェクトを成功させたプロジェクトマネージャーに注目が集まりやすい。でも、その裏側を支えているプラットフォームエンジニアリングも非常に重要です。当社のような企業でも、そこにしっかり投資し、評価していけば、開発の自動化は十分実現できる。

サミットに参加される方々の中には、私たちと同じように苦しんでこられた会社さんもきっといらっしゃるはずです。そうした方々に、「ここまでできるんだ」と感じてもらえるような話ができればと思っています。