deeptierが掲げるAIと人の協調による独自の開発手法「Human-AI Hybrid Development Method」。名前だけ聞くと「AIを使った開発ね」で終わってしまいそうですが、その背景には10年以上かけて積み上げてきた問題意識があります。
今回の記事では、この手法を設計したdeeptierエンジニアチームの中心メンバーである本田と正木の2名に話を聞きました。全3回のインタビュー連載、第1回はこの手法が生まれた背景です。
生成AIが出てくる前から、やりたかったことはあった
「最初の発想はシンプルで、生成AIで開発を自動化できたら楽やん、というところから来てるんです。ただし、『自動化』という発想自体は生成AI以前からありました。」と本田は話します。
たとえば、テーブル定義書からDDL（データベースの構造を定義するコード）を自動生成するツールは、ずっと昔から存在していました。テーブルの項目名やデータ型の形式はどのシステムでも共通のため、自動化できたのです。SQLを日本語の設計書から生成する試みも、同様に古くから行われていました。
「ただ、限界があったんです。決まった形式で書けるものは自動化できる。でも、業務ロジック——つまり、そのシステム固有のビジネスルールをコードにする部分は、どうしても自動化できなかった」（本田）
業務ロジックとは何か。たとえば「この条件のユーザーにだけこのアクションを許可する」「金額が一定を超えた場合に承認フローを挟む」といった処理です。テーブルの形式と違い、これは案件ごとに千差万別で、決まった型に落とし込めません。だからコードに変換する手順を自動化できなかったのです。
そこにChatGPT、Claudeといった大規模言語モデルが登場しました。
「自然言語で書いた仕様からコードを生成してくれる。これができるなら、今まで書けなかった"中身"が書けるんじゃないか、となったんです」（本田）
今まではスケルトン（骨格だけのコード）しか吐き出せなかったものに、生成AIが業務ロジックを書いてくれる。長年やりたかったことがようやく実現できる——それがこの手法の出発点です。
そして、本田がエンジニアとして様々な現場を渡り歩いた時代に、痛感し続けた問題があります。
品質が、人によってバラバラになる。
優秀なエンジニアが基盤を整え、実装ガイドラインをつくる。しかし、そのルールを守れるメンバーが揃わなければ意味がありません。高機能なフレームワークが「難しすぎて誰も使えない」という理由で流行らなかった歴史を、本田は何度も目にしてきました。
「たとえばJavaの時代、Hibernateというフレームワークは性能的に圧倒的だったんですよ。でも難しすぎて。結果、使いやすいMyBatisの方が普及した。優れたものでも、使える人がいなければ絵に描いた餅ですよね」（本田）
同じことがプロジェクト内でも起きます。実装ガイドラインをどれだけ丁寧につくっても、それを正しく理解してコードに反映できるかどうかはエンジニア個人の技術力に依存します。経験の浅いメンバーが多ければ、同じルールセットを渡しても出てくるコードの品質はバラつきます。
本田はこの問題を、生成AIの活用によって解決できると考えました。
「AIは難しいフレームワークであっても、ルールとして与えられればルール通りに実装してくる。人間の技術力のバラつきに左右されません」（本田）
実装ルール、アーキテクチャの方針、命名規約——これらをプロンプトとして与えれば、AIは毎回同じ基準でコードを書きます。ベテランがいようと、経験の浅いメンバーが多かろうと、アウトプットの品質が人に引っ張られることがなくなります。
本田はこう言います。「システム開発会社の真の実力は、最高品質がどこまで出せるかじゃなくて、最低品質ラインをどこまで引き上げられるかだと思っている」。生成AIはその最低ラインを、これまでとは別次元の高さに設定することを可能にした——それがこの手法の根幹にある思想です。
人がやるべきこととAIがやるべきこと
ただし、「AIに任せれば何でもできる」という話ではありません。本田が「システム開発で一番難しい部分」として挙げる、こんな問題があります。
「オレゴン大学の実験」（C.アレグザンダ―・他著，B6判，203p，鹿島出版会，1977年12月）
画像引用：https://xtech.nikkei.com/it/article/COLUMN/20080828/313626/
「お客さんが『こういうものが欲しい』と説明する。それを聞いたエンジニアが各々に解釈してつくる。できあがったものを見たお客さんが『全然違うんやけど』と言う」（本田）
要件を正確に言語化するのが難しい。言語化されても人によって解釈がズレる。「乗れればいい」と言ったはずなのに豪華な椅子がついてきた——そんなズレは今もどこかの現場で起きています。このギャップを埋める作業は、AIには現時点でできません。「何を作るか」を決める上流は、人間がやるしかないのです。
では、要件が決まってコードを書く段階はどうなのか？
「設計書さえちゃんとしたものができていれば、必ず約束された品質以上のものが上がってくる、という状態をつくりたい」と本田は言います。
実装ルールをAIへの入力として与え、設計書に従ってコードを自動生成させることで、人間が無意識にやっていた「コントローラーを書くときは実装ガイドラインのコントローラーの章を見る」という動作を、プロンプトとして明示的に与えてやる。そうすることで、誰が関わっても一定以上の品質が担保されたコードが出てきます。
もちろん、途中で要件が変わるケースもあります。「Aだと思っていたものがBに変わります」——このとき、影響を受ける機能はどこか、どの設計書をどう修正すべきかの判断は人間がやるべき領域です。しかし、設計書を正しく修正しさえすれば、そこからの再実装はAIが担います。
人間が上流を握り、AIが実装を担う。この役割分担の境界線を明確にし、プロセスとして整備したものが「Human-AI Hybrid Development Method」です。
この手法がもたらす変化で、本田が特に強調するのが設計書とコードの一致です。
従来の開発では、設計書とコードが乖離することは日常茶飯事でした。途中で要件が変わっても設計書を更新しないまま実装を進め、最終的にコードだけが真実となる——そんな現場は珍しくありません。保守をする人間は、設計書ではなくコードを読んで仕様を類推するしかなくなります。
「設計書を直せばコードが直る。この状態をつくれるのが大きい」と本田は言います。
設計書が生成AIへの指示書として機能している以上、設計書が正しければコードも正しくなります。ドキュメントとコードが常に同期した状態を保てます。
この変化は、要件定義フェーズにも波及します。「画面イメージを早い段階でお客さんに確認してもらうのは大事なのに、工数がかかるからモックをつくらないままプロジェクトが進んでしまうことが多かった」と本田は言います。生成AIを使えば、このプロセスのスピードが格段に上がります。認識のズレを前倒しで潰せるようになるのです。
テストについても同じ構造があります。
「Unit Testのツールは10年以上前からある。でも普及しなかったのは、テストコードを書くと実装工数が単純に倍になるからです」（本田）
本番コードを書きながらテストコードも書く——人間がやると負担が重すぎました。しかし生成AIにやらせれば、その追加負担はほぼゼロになります。「人がやると工数2倍になるけど、AIにやらせればいい」という判断が、これまでできなかった品質施策を次々と可能にしていったのです。
インターネット上には「Claude Codeを使えば2日でSaaSが作れる」といった言説が溢れています。これについて、本田は率直に言います。
「動くものをつくるだけなら、それは事実かもしれない。でも、実運用に耐えられるか、セキュリティは問題ないか、半年後に別の機能を追加しようとしたとき保守できるか——そこまで含めて考えたら、話は全然違います」（本田）
正木も同様の見方をします。
「実装力という点では生成AIはかなり高い。でも、それをレビューする力、設計する力は人間が持っておかないといけないですね」（正木）
生成AIが出力したコードをそのまま通すのではなく、品質の基準を持った人間がレビューし、ゲートをくぐらせる——その仕組みがあって初めて、速さと品質が両立します。
生成AIに伝わる形でルールを言語化できる人間がいなければ、そもそもAIに正しいものはつくれません。生成AIを使いこなすには、使う側の人間の水準が問われるのです。
「Human-AI Hybrid Development Method」という言葉は、後からついてきたものです。本田がエンジニア時代に現場で見続けた「品質が一定しない」という問題意識、そして「設計書からコードまで自動化できたら」という長年の構想——その二つが、生成AIの登場によって初めて接続されました。
人間がやるべきことはあります。上流の要件を引き出し、設計書に落とし込み、変化があれば影響範囲を見極め、生成AIが出してきたものを評価する。その役割は消えないし、むしろAI時代においてより重要になっていきます。
一方で、実装という作業の大部分はAIに任せられます。ルールを正しく与えれば、AIは疲れず、ブレず、毎回同じ基準でコードを書きます。
「AIが万能なんじゃなくて、人間が注力すべき仕事に集中できるようになる。そこが一番大きいです」（本田）
本田の言葉は、この手法の裏側にある思想を一言で表しています。
そして、「Human-AI Hybrid Development Method」という名称も、偶然ではありません。HumanがAIより先に来ているのは、人間が主役であるという意思の表れです。
道具の使い方を決めるのは、いつでも人間です。
【deeptierのシステム受託開発】現状の課題やビジネスゴールについて、壁打ちベースからご相談を承ります。
【本記事の監修者】
本田 哉樹
株式会社deeptier マネージャー
Web系企業での開発経験を通じて、日本のシステム開発が抱える構造的な問題を肌で感じ、フリーランスとして独立。 独立後は、炎上・崩壊寸前のプロジェクトへの参画を主戦場とする。
曖昧な責任体制、形骸化したプロセス、意思決定の停滞——こうした状況を「前提条件」として受け入れ、機能しないものを整理し、成果が出る構造に組み直すことをキャリアを通して積み重ねる。顧客折衝・設計・実装・進行管理を統合することで、情報の分断による遅延を排除し、様々な技術・環境においても再現性のあるシステム開発をリード。
「エンジニアの価値は知識量ではなく、未知を即座に戦力化して成果につなげられるか」が持論。各現場で得た知見を共通構造として抽出・再構築することで、Human-AI Hybrid Development Methodの設計思想に至る。
正木 拓馬
株式会社deeptier エンジニアリーダー
海外大学にてソフトウェア工学を専攻し、欧州企業にてWebアプリケーション開発に従事。多国籍チームでの開発経験を通じ、グローバル環境における実践的な知見を有する。
人材紹介会社では、社内ユーザー数100万人規模の基幹システムにおいて、フロントエンドからバックエンド、バッチ処理までを横断した設計・開発を担当。拡張性・保守性を重視したアーキテクチャ設計および開発プロセス改善を推進。
現職では、Webアプリケーション開発基盤の設計・標準化を主導するとともに、AIを活用したコード生成パイプラインおよび品質管理プロセスの設計・導入に従事。実務に根ざした開発基盤設計およびプロセス改善を専門とする。
※この記事について
本インタビューは2026年5月に実施いたしました。肩書や所属はインタビュー実施当時のものであり、インタビュー時点の一般的な開発情報に基づいて執筆されています。技術トレンドの変化により、推奨されるツールや手法は変わる可能性があります。
記事／構成：deeptier マーケティングチーム