AI-DLC 開発
AI 駆動型開発ライフサイクル
AI-DLC とは、要件定義・設計・実装・レビュー・テスト・運用というソフトウェア開発の全工程に AI が関与し、その方向づけと結果への責任はエンジニアが負うという進め方です。「AI がコードを書く」ことではありません。機械的な作業を AI に任せ、人が判断に集中するための、規律のあるライフサイクルです。
1 つのループ、1 つの仕様
どの工程も同じ仕様書を読み、その結果を仕様書へ書き戻します。モデルとエンジニアとレビュー担当が、似て非なる 3 つのシステムではなく 1 つのシステムをつくり続けられるのは、そのためです。
進め方の原則
仕様を起点に
要件と受入条件は文書化し、常に最新に保ちます。人も AI も、それを基準に実装するからです。
レビューを通した生成
AI 支援による実装も、人によるレビュー、自動テスト、静的解析を必ず通してからマージします。例外はありません。
継続的な検証
すべての変更にテストが伴います。出荷可否を判断するのは担当者ではなくパイプラインです。
判断の記録
アーキテクチャ上の意思決定はその都度記録します。理由が契約期間を超えて残るようにするためです。
3 つの事業領域
新規開発はそのうちの 1 つにすぎません。止められないシステムの移行、そして貴社チーム自身がこのライフサイクルを回せるようにするご支援も、同じ比重で担っています。
01 / 03事業領域
AI-DLC によるソフトウェア開発
AI 駆動型ライフサイクルのもとで、新規システムを一貫して構築します。要件・設計・実装・レビュー・テストの機械的な作業を AI が担い、判断とマージの責任はエンジニアが持ちます。
- 仕様と受入条件を先に文書化し、最新に保ち、人とモデル双方の実装契約として使います
- AI 支援による実装は、人によるレビュー・自動テスト・静的解析を必ず通します
- アーキテクチャ上の判断はその都度記録し、決めたチームより長く理由が残るようにします
- 出荷可否を判断するのは担当者ではなくパイプラインである、継続的デリバリー
標準的な期間3 – 9 か月
02 / 03事業領域
移行とモダナイゼーション
止められないシステムを動かします。人手では追いつかない速度で AI がレガシーコードを可読化し、移行そのものは単独で出荷できる単位に分けて進めます。
- レガシー評価：依存関係と呼び出しグラフの可視化、デッドコードの特定、そして資料が失われた箇所の挙動をコードから復元
- 段階的なストラングラーフィグ移行。新しい機能を前面に置き、旧システムを経路単位で退役させ、トラフィックが実際に移りきるまで両系を並走させます
- 再プラットフォーム化と再設計：ランタイムとフレームワークの更新、割に合う範囲でのモノリス分割、そして割に合わない場合は率直にそうお伝えします
- 突合を伴うデータ移行：スキーマの対応付け、バックフィル、二重書き込みまたは二重読み出し、そして書面だけでなく予行演習を済ませた切り戻しを備えた切替
標準的な期間4 – 12 か月
03 / 03事業領域
AI-DLC トランスフォーメーション
私たちが代行するのではなく、貴社チームがこのライフサイクルを身につけるためのご支援です。HCT の人間が同席しなくても回るようになった時点で完了です。
- 現在の開発プロセス、ツール、制約の評価。セキュリティ部門と法務部門が何を許可し、何を許可しないかまで含めて確認します
- ツール整備：AI コーディングツール、リポジトリ規約、レビューゲート、そしてレビューを経ない生成コードを本番に入れないための CI チェック
- エンジニア、レビュー担当、QA、プロダクトそれぞれに向けた役割別トレーニング。チュートリアル用のリポジトリではなく、実際のコードベースで行います
- 伴走付きのパイロット、そして引き継ぎ：プレイブック、社内の推進役、そしてパイロットで何が変わり何が変わらなかったかの率直な振り返り
標準的な期間6 – 12 週間
AI が担うこと、エンジニアが持つこと
意味のある問いは「AI を使うかどうか」ではなく「AI にどの判断を許すか」です。答えはひとつも許しません。すべての案件で適用している工程ごとの分担を、そのまま示します。
要件定義
AI が担う
いただいた情報からストーリーと受入条件の草案を起こし、要件どうしが矛盾している箇所を指摘します。
エンジニアが持つ
対象範囲、システムが決してしてはならないこと、そして各矛盾をどちらに寄せて解消するか。
設計
AI が担う
設計案を複数出し、それぞれを提示された制約と突き合わせ、判断記録の初稿を書きます。
エンジニアが持つ
アーキテクチャ、そこで受け入れるトレードオフ、そしてプロジェクトより長く残る判断記録への署名。
実装
AI が担う
仕様に沿ってコードを書き、リポジトリ既存の規約に合わせ、テストも同時に用意します。
エンジニアが持つ
コードが収まるべき境界、そして共有ブランチに入る前に全行を読むこと。
レビュー
AI が担う
明らかな欠陥、不足しているテスト、規約からのずれを先に洗い、人のレビューがきれいな差分から始まるようにします。
エンジニアが持つ
承認するか差し戻すか。AI の一次確認がその代わりになることはなく、承認者名のないブランチはマージされません。
テスト
AI が担う
人が飛ばしがちな境界条件も含めてケースを生成し、スキーマ変更にフィクスチャを追従させます。
エンジニアが持つ
「正しい」の定義、どの失敗がリリースを止めるか、そして壊れたまま本番へ出たときの説明責任。
運用
AI が担う
インシデントを要約し、ログとトレースを突き合わせ、最初の仮説を提示します。
エンジニアが持つ
判断と対処、そして深夜 3 時の呼び出し。
ゲートはどこにあるか
ゲートのない速さは、同じ欠陥へ早く着くだけです。この 3 つは自社の仕事でも貴社の仕事でも動かしません。トランスフォーメーション案件で最初に整えるのも、この 3 つです。
レビューなしにマージされない
生成されたコードも手で書いたコードも通る経路は同一です。まず自動チェック、次に名前のある承認者。ブランチ保護で強制しているため、余裕のない週に誰かが踏みとどまれるかどうかには依存しません。
判断するのはパイプラインで、人ではない
テスト、静的解析、依存関係とシークレットのスキャンがすべてグリーンである必要があります。期日が近いからと押し通す人は現れません。押し通す仕組みが存在しないからです。
出自を記録する
コミットには「どう作られたか」が、判断記録には「なぜそうしたか」が残ります。半年後でも、何が生成され、何がレビューされ、誰が承認したかを追えます。
取り扱う技術
案件ごとに選定します。どの案件にも当てはめる自社標準スタックは持ちません。お客様のチームがすでに保守されている技術に合わせます。
言語とフレームワーク
貴社チームがすでに保守されている技術で開発します。動いているシステムを私たちの得意な言語へ書き換えるのは、こちらの都合にお客様が費用を払うことです。
- TypeScript
- Python
- Java
- Spring
- Go
- .NET
- React
データと基盤
構築したシステムが動く実行基盤と、モダナイゼーションであればそこへ入る／そこから出る移行経路。
- PostgreSQL
- Redis
- Kafka
- Docker
- Kubernetes
- Terraform
- AWS
- Azure
品質ゲートとデリバリー
AI 支援の開発を「速いが後悔する」ものにしないのがゲートです。自社の仕事では譲らない部分であり、お客様の環境にも同じ形で整えます。
- Claude Code
- Git
- GitHub Actions
- SonarQube
- Playwright
- Vitest
- OpenAPI
- ADRs
プロジェクトの流れ
1 – 3 週目
把握
要件、制約、そして移行案件であれば既存システムの実際の挙動。成果物は提案スライドではなく仕様書です。
2 – 5 週目
設計
アーキテクチャ、インターフェース、テスト戦略、レビューゲート。各回の「完了」の定義は、その回を始める前に合意します。
2 か月目以降
実装
2 週間ごとに区切り、その終わりには必ず何かがデプロイされている状態にします。AI が速めるのは区切りの中身であり、その周りのゲートは動かしません。
最後の 2 – 4 週間
引き継ぎ
ドキュメント、Runbook、判断記録、そして今後保守されるチームとの実作業セッション。トランスフォーメーション案件では、ここ自体が目的です。
お手元に残るもの
- 最後にまとめてではなく、区切りごとに本番へ届く動くソフトウェア
- なぜこの形になったのかを説明できる仕様書と判断記録
- 私たちがいなくても実行・拡張できるテストスイートとパイプライン
- 移行案件では、突合済みのデータ切替と、予行演習を済ませた切り戻し
- トランスフォーメーション案件では、ガードレールが整った状態で自社エンジニアがライフサイクルを回している状態
この領域でご相談はありますか
課題の輪郭をお聞かせください。私たちが適任かどうか、正直にお答えします。