AI-Native Document Driven Development
AI Native Document Driven Development

AIには、コードを生成してもらうだけでなく、
テスト検証、ドキュメント反映までを徹底しておこなってもらう。開発を常に前へ進められる状態をつくる。

構想、要件定義、PoC、実装、運用まで
一気通貫で支援します。

強みは、クライアントの課題を聞き取り、業務の流れを整理し、必要な機能へ分解し、実際に動くシステムとして完成させられることです。AIを活用しながら、企画や要件をドキュメント化し、タスクに分解し、コードへ落とし込み、実装結果を再びドキュメントへ還元します。

AI-DDD
AI-DDD PROCESS

AI-DDDの開発プロセス詳細

ヒアリングから要件定義まで、各工程でAIとドキュメントを活用しながら開発を前へ進めます。

01

ヒアリング 60〜90分

会話を録音させていただきます。AI議事録と構造化データとして保存します。

02

開発環境構築 1分

プロジェクトディレクトリの作成。VS Code上で、CodexとClaude Codeを使ったドキュメント作成ができる準備をします。

03

要求整理 30分

字おこしした議事録をもとに、NotebookLMでデータを構造化します。全体のスライド、議事録としての再生成、論点ごとのレポート、インフォグラフィックを生成し、要求へ整理します。スライドやインフォグラフィックは認識あわせとして利用します。

04

要件定義 第一版作成 2時間

要求を実現するために必要となるシステム構成を考慮しながら機能要件だけでなく、さまざまな視点でドキュメントを作成します。

要件定義が終わった時点で、PoC開発、MVP開発、フェーズNの開発計画ができている状態を目指します。

プロダクト概要 機能一覧 画面/導線 主要モデル定義 非機能要件 権限 業務フロー 運用 データアーキテクチャ 外部連携 テスト方針 リリース手順 デプロイ / インフラ設計書 データ移行手順書 GitHub Issue 草案 チケット管理運用ガイド GitHub運用のあるべき姿
実例:ec-plus1プロジェクトのドキュメント一覧
ドキュメント名ファイル
ドキュメント一覧docs/README.md
プロダクト概要docs/product-overview.md
ECサイトとフリマサイトの差分整理docs/ec-vs-flea-market-spec.md
機能一覧docs/feature-list.md
MVPタスク一覧と実行計画docs/mvp-task-plan.md
Post-MVP計画docs/post-mvp-plan.md
画面 / 導線仕様docs/screen-flow-spec.md
ヘルプ仕様docs/help-spec.md
ヘルプ記事下書きdocs/help-article-drafts.md
権限仕様docs/authorization-spec.md
注文 / 決済フロー仕様docs/order-payment-spec.md
結合テスト仕様docs/integration-test-spec.md
運用手順docs/operations-runbook.md
商品モデル定義docs/product-model-spec.md
売上・入金運用仕様docs/sales-operations-spec.md
監査ログ仕様docs/audit-log-spec.md
非機能要件docs/non-functional-requirements.md
データアーキテクチャ設計docs/data-architecture-spec.md
外部連携仕様docs/integration-spec.md
テスト方針docs/test-strategy.md
リリース手順docs/release-checklist.md
ルーティング責任マップdocs/routing-responsibility-map.md
次フェーズ設計方針docs/next-phase-design-spec.md
デプロイ / インフラ設計書docs/deployment-spec.md
監視アラート定義書docs/monitoring-spec.md
データ移行手順書docs/data-migration-guide.md
新業種サイト セットアップガイドdocs/new-site-setup.md
未実装領域のクリティカル分析docs/unimplemented-critical-analysis.md
残存課題および次フェーズ検討事項集約レポートdocs/remaining-issues-next-phase-report.md
次フェーズ実装バックログdocs/next-phase-backlog.md
GitHub Issue 草案docs/github-issue-seeds.md
GitHub Epic 草案docs/github-epic-seeds.md
チケット管理運用ガイドdocs/ticket-management-policy.md
GitHub Projects カラム設計docs/github-projects-configuration.md
GitHub Projects 初期投入計画docs/github-projects-seeding-plan.md
GitHub運用のあるべき姿docs/github-operating-model.md
ec-plus1 戦略チェックリスト 2026docs/ec-strategy-checklist-2026.md
05

設計 2時間

要件を元に、データ構造の設計、全体の共通部分の切り分けなど、機能一覧・画面一覧・共通API・データベース構造などに物理的に分けられるように設計します。

データ構造の設計

  • どんなテーブルが必要か(例:users, orders, products)
  • テーブル同士の関係(1対多、多対多など)
  • 各カラムの型・制約

画面・機能の切り分け

  • どの画面が存在するか一覧にする
  • 画面ごとにどのAPIが必要かを決める
  • 管理画面・フロント・APIなど物理的な分離

共通部分の特定

  • 認証・権限まわりはどこで管理するか
  • 複数機能で使い回せるコンポーネントは何か
  • ミドルウェアやサービス層に何を置くか

コードを書く前に、何をどこに置くかを決める作業です。これをやらないと、実装が進むにつれて矛盾や重複が出てきます。

06

開発環境構築2 15分

Dockerコンテナ / Git / GitHub連携を構築します。

07

GitHub Issue登録 5分

いよいよコード生成。そのまえに、要件をタスクとしてIssueに分解し、GitHubへ登録してもらいます。実装はIssue単位で進めます。

08

プログラム開発 プロジェクトの工数により異なる

Claude Code・Codex を使い分けてプログラムコードを生成します。Issue単位にプログラム作成・ユニットテストまでを実施します。

09

動作確認によるバグ修正

できあがった部分から動作確認をしながら、問題があればPRとして登録します。

10

ドキュメント反映

1日の最後に、修正を反映したうえで問題なければ、修正内容をすべてドキュメントへ反映してもらいます。READMEへの進捗更新、各ドキュメントの変更点など、常に最新の状態を維持します。

11

日々のルーティン

「今の状況を教えて」と聞くと、ドキュメントの進捗・直近のcommit/push・Issueの解決状況などを報告してくれます。そして「次はこのタスクをやるのがおすすめです」と提案してくれます。それに対して「はい」と答えるだけで開発が前へ進みます。

STRENGTH

得意なこと

単なる開発担当ではなく、課題解決人として、課題整理から実装・運用までをつなぐ実務型の開発支援を行うことができます。いかにして実現するかを考え抜きます。

01

要件定義・業務整理

漠然とした相談であっても、現在の状況をもとに業務フロー、画面、データ、機能単位へ整理します。

02

PoC推進

コンテナ環境で小さく試して、実現性・効果・課題を早期に確認します。特にローカルAIの検証や、AIに関わる実装技術、PostgreSQLを使ったpgvectorでのベクトル意味の近似値検証などを得意としています。

03

実装力

サーバサイドはLaravelを中心に、管理機能やAPI提供を担います。フロントは簡易的な画面であればBladeですが、機能的要件が高い場合にはReact・React/Next.js・Vue.jsなどのフロントエンド開発実装も可能です。サーバ構築からアプリケーションまで実装します。

04

AI活用

Claude・ChatGPT・Geminiなどの生成AIを、開発・業務改善・文書解析・設計支援に実践的に組み込みます。AIに何ができるかではなく、どう使えば現場で動くかを軸に実装します。ローカルLLMの構築から、RAG・ベクトル検索・プロンプト設計まで、AI活用の実務経験が強みです。

AIネイティブ・ドキュメント駆動開発
AI-DDD

AIを活用し、要件定義・設計・実装・運用を分断せず、一つの循環として回す開発プロセスです。打ち合わせ内容や既存ドキュメントを構造化し、仕様・タスク・コードへ変換。さらに実装結果をドキュメントへ還元し、常に最新の状態を維持します。

PHASE 01

抽出・蒸留

議事録、要望、既存資料を整理し、開発に使える構造化ドキュメントへ変換します。

PHASE 02

研磨・分解

AIとの対話で仕様の矛盾や抜けを洗い出し、GitHub Issueなどの実装タスクへ分解します。

PHASE 03

自律実装・検証

Claude Code、Docker、テスト環境を活用し、実装と検証を繰り返して品質を高めます。

※ このセクションには、AI-DDDの循環エコシステム図を掲載すると、開発スタイルの独自性が伝わりやすくなります。
AIネイティブ・ドキュメント駆動開発 AI-DDD
PRINCIPLE

AIには、コードを生成してもらうだけでなく、
テスト検証、ドキュメント反映を徹底する。

開発を常に前へ進められる状態をつくる。

01

コード生成

要件・仕様をもとにAIが実装を担当。人間は判断と設計に集中します。

02

テスト検証

生成したコードをAIが自律的に検証。不整合や抜けを早期に発見します。

03

ドキュメント反映

実装結果をドキュメントへ還元。次の開発が常に最新の情報から始まります。

Q&A

よくある質問

PoCとMVP開発は違いますか?

PoC(Proof of Concept)は「これは実現できるか?」を確かめるものです。精度・技術的な実現性・業務への組み込み可能性を小さく試します。捨てることが前提です。

MVP(Minimum Viable Product)は「最小限でも実際に使えるプロダクト」を作るものです。ユーザーに届けてフィードバックを得ることが目的で、捨てません。

開発の流れとしては、PoCで実現性を確認してからMVPを作るという順番が自然です。

PoC 「できる」を確認 MVP開発 リリース 改善
POC

PoCとは、本開発前に小さく試す検証フェーズです。

Proof of Conceptの略で、「本当に実現できるか」「効果が出そうか」を小さく確認するための取り組みです。

PoC = 小さく試して、判断材料を作ること

いきなり大きく開発するのではなく、最小限のデータ・画面・機能で実現性を確認します。

PoCで確認すること

PoCの目的は、作り込むことではありません。本開発へ進めるべきかを判断するための材料を作ることです。

AIで期待する精度が出るか
業務フローに組み込めるか
使えるデータが揃っているか
現場で使える画面・操作になるか
本開発に進める価値があるか
EXAMPLE

PoCの具体例

PDF議事録解析AI

PDF数本を対象に、発言者・課題・答弁・成果を抽出できるか検証します。

社内文書検索AI

既存資料を取り込み、質問に対して正しい根拠付き回答が返せるか確認します。

業務システム試作

登録・検索・一覧・詳細など、業務フローの一部だけを先に作って確認します。

EC・注文管理

商品、カート、注文、管理画面の最小フローを通して、運用可能性を確認します。

AIチャットボット

問い合わせ履歴やFAQをもとに、回答品質・運用負荷・改善余地を検証します。

マッチング・検索機能

条件検索、推薦、比較など、サービスの核になる機能を小さく試作します。

PROFILE

技術と事業の両方を見ながら、実装まで進める。

20歳の頃にC言語とUNIX環境で開発を学び、LSI開発企業への出向でエンジニアリング系の開発を学び、その後30代は大規模開発案件のプロジェクトマネージャーを経験。2005年に株式会社iPLUS ONEを設立し、WEBアプリケーションの受託開発を中心にやってきました。現在はAIを最大限活かした開発プロセスAI-DDDを実証実験中です。

AI活用やWebシステム開発を、小さく試すところから始められます。

課題整理、PoC、要件定義、実装、運用まで、現実的な進め方で支援します。

相談する