AIで開発を前倒しする、CMSサイト構築ワークフロー

AIで開発を前倒しする CMSサイト構築ワークフロー プロトタイプを使って、要件定義から設計・開発まで進める 柳谷 真志 @mersy bit part 合同会社 / 株式会社ミツエーI'O 2026年6月20日 新潟グラム 1

自己紹介 mersy / まーしー / 柳谷 真志 青森県青森市出身、東京都在住 bit part 合同会社 / 株式会社ミツエーI'O CMS案件のディレクションや設計、チーム開発の進行管理を主に担当 クライアントとのやりとり、プロジェクト管理、設計のベースづくりが中心 Movable Type、Craft CMS、Drupal、PowerCMS Movable Type歴 約20年 2

bit part 合同会社 CMSを使ったWebサイト構築を中心にしている制作会社 使いやすいCMSを重視し、MTプラグイン MTAppjQueryを開発・提供 Movable Type、Craft CMS、PowerCMSを中心に、各種CMSを扱う Six Apart ProNet / Craft CMS 公式パートナー 東京、ニュージーランド、秋田、北海道のメンバーでリモート中心に制作 HAMWORKSとも協働 3

今日話すワークフロー 要件定義はもともと、プログラムを書かなくてもできた。 AIでプラグインやカスタムモジュールのたたき台まで作れることで、 要件定義の精度が上がる。 01 02 03 04 要望を聞く AIでプロトタイプ 動かして確認 実装へつなぐ 私 + クライアントで やりたいことを整理 → CMS設定 テンプレート 実装たたき台 入力画面 公開画面 検索・権限 確認観点 判断材料 レビューへ ディレクターでも、開発寄りの大きな論点を動くもので確認してから要件へ落とせる。 4

今回の例の背景 Drupalで構築された既存サイトに、 別サイトの内容を統合するプロジェクト。 新しくHTMLを先に作るより、 既存の部品にどうCMSから出すかが論点だった。 既存サイト デザイン、HTML/CSS、Drupal用コンポーネントはすでにある。 今回やること 別サイトの内容を、既存サイトの構造と見た目に合わせて統合する。 考えること ページや機能を、どのCMS設定・テンプレート・コンポーネントで表現するか。 5

このプロジェクトで回したワークフロー 人間が集める クライアントの要望、既存サイトの設計書、会議メモ、既存画面を材料として渡す。 AIが分解する ページ、機能、入力項目、一覧、検索、権限を要件 / 設計 / タスクへ分ける。 AIが作る Drupal config、Twig、Views、Search API、custom module のたたき台を作る。 人間が確認する 権限、公開範囲、編集者の入力しやすさ、運用が問題なさそうかを確認して修正指 示を出す。 6

Drupal config を動く設定にする → → 7

動く画面で確認する ⼊⼒画⾯ 公開画⾯ 検索・権限 編集者が⼊⼒できるかを確認 既存コンポーネントで表現できるかを確認 後⼯程に回りがちな論点を確認 タイトル コンテンツ⾒出し ページタイトル 公開範囲 ⼀般公開 公開範囲や分類に応じて表⽰を切り替える。 限定公開 関連カテゴリ カテゴリ A カテゴリ B カテゴリ C 下書き保存 ⼊⼒しづらさ、権限、項⽬過不⾜を⾒る ID指定 検索条件 年度 / カテゴリ / 公開状態 表⽰権限 anonymous: view public カテゴリ 既存部品へ合わせる member: view limited editor: edit / publish HTML/CSSを作り直すのではなく、 CMS出⼒と部品の差分を確認する。 カスタム実装候補 公開画⾯で、想定と違う箇所を早く⾒つける 検索・公開範囲・権限を実装前に論点化 標準機能で⾜りない検索条件を補う 入力画面、公開画面、検索、権限、公開範囲を見ながら、テキストだけでは見えない運用上の論点を確認する。 8

仕様を小さく分ける specs / feature / files specs/ ├─ content-management/ │ ├─ requirements.md │ ├─ design.md │ └─ tasks.md ├─ permission-management/ │ ├─ requirements.md │ ├─ design.md │ └─ tasks.md ├─ full-text-search/ │ ├─ requirements.md │ ├─ design.md │ ├─ tasks.md │ └─ open-questions.md └─ custom-module/ ├─ requirements.md ├─ design.md └─ tasks.md AIに渡すための整理 要望や既存資料を、機能ごとの requirements.md / design.md / tasks.md へ分解する。 AIは扱いやすくなるが、人間には全体像や置 き場所が見えづらくなる。 9

分けた仕様を要件定義書に戻す CMSサイト統合 要件定義書 5.1 コンテンツ管理 既存CMS標準機能をベースに、専用の編集・公開設定を追加する。 5.4 公開範囲制御 一般公開 / 学内公開 / ID指定をコンテンツとファイルへ適用する。 6.2 検索・一覧 分類、年度、公開状態を条件に一覧と検索結果を表示する。 人間が読む形へ 細かい仕様群とプロトタイプ確認結果 を、機能要件・非機能要件・受入条件へ まとめ直す。 クライアント説明や後工程への引き継 ぎでは、この形が必要になる。 受入条件 編集者が入力し、想定した公開範囲で公開画面に反映される。 10

カスタム実装の論点を早く見つける custom module draft 実装たたき台 custom_feature/ ├─ custom_feature.info.yml ├─ custom_feature.module ├─ src/ │ ├─ Form/ │ │ └─ SearchConditionForm.php │ └─ Plugin/ │ └─ views/filter/ │ └─ CategoryFilter.php └─ config/install/ ├─ views.view.content_list.yml └─ search_api.index.content.yml function custom_feature_form_alter(&$form) { $form['category']['#type'] = 'checkboxes'; $form['category']['#options'] = $options; // 入力条件を Views / Search API へ渡す $form['actions']['submit']['#submit'][] = 'custom_feature_search_submit'; } 標準機能で足りない部分を、動く前提で論点化する。 11

なぜこれが効くのか 実例を踏まえて、従来のCMSプロトタイプとの違いを見る 12

従来の進め方と限界 01 02 03 04 仮設定 見た目 データ 確認 コンテンツタイプ フィールド 汎用テンプレート 簡単なHTML サンプル入力 一覧 / 詳細 触ってもらい 要件を詰める 動くものがあると、クライアントもイメージしやすい。 ただし、手間のかかる設定や実装は後工程へ送られがちで、 実装後に想定違いが分かると手戻りが大きくなる。 作りやすい 基本フィールド / 汎用テンプレート / サンプルデータ / 単 純な一覧 後回しになりやすい 権限 / 公開範囲 / 複雑な検索 / プラグイン / カスタムモ ジュール 13

AIで「短く」×「広く」 工程全体はウォーターフォール寄りでも、 要件定義の中で開発寄りの論点まで動かし、確認ループを短く・深くできる。 短くなる 深くなる 要望を聞く 入力画面 / 公開画面 AIでCMS設定や実装たたき台を作る コンテンツタイプ / フィールド 動くもので確認する 権限 / 公開範囲 / ワークフロー 要件・確認観点へ反映する 検索 / ブロック プラグイン / カスタムモジュール → 体感として大きいのは、開発フェーズで初めて見えていた権限、検索、カスタム実装の論点を、要件定義中に確認できる こと。 14

AIが作るたたき台 現行仕様メモ 部品対応表 CMS設定のたたき台 表示テンプレート 拡張実装案 既存サイトや設計資料から、ページ分類、コンテンツタイプ、フィールド、一覧候補を洗い出 す。 既存コンポーネントとCMS出力を対応付け、どの部品で表現できるかを確認する。 Drupal config、Craft Project Config、MT / PowerCMS theme、API などで、設定案を動 く形にする。 CMS出力と既存HTML/CSSの差分を埋め、入力画面と公開画面を確認できる形にする。 標準機能で足りない部分は、プラグイン / カスタムモジュールをAIに作らせ、実現方法と運 用イメージを確認する。 15

プロトタイプから要件定義書へ 人間が要望を残す AIが仕様群を更新する AIが要件定義書へ再編 集する 人間が確認して渡す 動くものを見て出た変更、判断、保留事項を、誰の要望か分かる形で追記する。 cc-sddなどで、要件 / 設計 / タスク / 確認事項 / 未確定事項へ再整理する。 分散した仕様とプロトタイプの確認内容を、機能要件、非機能要件、受入条件、検証方法へ 組み替える。 クライアントに説明できるか、開発工程へ渡せるか、未確定事項が残っていないかを見る。 プロトタイプは論点を見つけるためのもの。 仕様駆動は、その論点を要件定義書として残すために使う。 16

参考: 仕様駆動で整理する cc-sdd 要望を機能ごとの requirements.md / design.md / tasks.md へ整理・分解する 入口として使う。 仕様駆動開発 整理した仕様を正本にして、CMS設定、実装、検証を進める考え方。 Traceability 要望 -> 要件 -> 実装たたき台 -> 受入条件の対応を追えるようにする。 使い分け cc-sddは分ける入口。仕様駆動開発は進め方。Traceabilityは後から確認する線。 cc-sdd: 仕様駆動開発をAIと進めるためのテンプレート / コマンド群 https://github.com/gotalab/cc-sdd 17

• https://github.com/gotalab/cc-sdd

前倒ししたものを誰が引き取るか 今回の例はディレクターからエンジニアへ。 同じ構図は、ディレクター・デザイナー・フロントエンドエンジニアなどの分業でも起きる。 従来 仕様や依頼を受ける 担当範囲を実装する 成果物を出す レビューを受ける ! AI前倒し型 AI生成物と意図を把握する 使う / 捨てるを判断する 必要部分を調整して取り込む 品質責任を持つ そのまま使えるものも多い。ただし、意図の把握・採用判断・品質責任は人間側に残る。 18

まとめ AIで動くものを素早く作り、要件定義中にクライアントや関係者と短いフィードバックループを回す。 特にプラグイン / カスタムモジュールのたたき台まで動かせると、要件の解像度が一段上がる。 HTML先行かCMS出力基準かより、CMSで運用できる構造を動く形で早く確かめる。 プロトタイプで見えた要望・仕様・実装上の論点を、仕様駆動で整理し、後工程の判断材料として渡す。 19

ご清聴ありがとうございました @mersy （柳谷 真志） Update bit part, everyday!! MT::Lover::bitpart 20