ある月刊専門誌の編集部には、毎号くり返す地味で重い作業があった。誌面のワイヤーフレーム(構成ラフ)づくりだ。どこに見出しを置き、何文字くらい入れ、写真を何点並べるか——担当者が毎回、手で組む。1本あたり2〜3時間。私たちはこれを、オリエンシートを入力 → AIが構成案を出す → ワイヤーフレームが出力されるまでを15分以内で完結する社内ツールに畳んだ。設計から本番まで実働1セッション、運用は月¥450〜。さらに、本番投入後のクライアントの一言で、出力エンジンごと作り替えた。「速く作る」だけでなく「使われ始めてから、正しく作り直す」までが入った制作事例だ。その中身を、設計判断ごと開示する(顧客・媒体名は伏せた匿名ケーススタディ)。

01何を作ったか:2〜3時間を、15分に
作ったのは、編集者が使う業務ツールだ。流れはシンプルにした。
- ① オリエンシートを入力:企画の意図・ページ数・トーンなどをフォームで埋める。
- ② AIが構成案を生成:過去の誌面ナレッジを参照しながら、見出し・要素・分量の構成案を出す。チャットで修正指示も出せる。
- ③ ワイヤーフレームを出力:確定した構成案から、誌面レイアウトのラフを自動生成する。
ただ画面を作っただけではない。構成案は過去の誌面ナレッジ(PDF)を参照して出すので、その媒体らしさが効く。出てきた案にはチャットで修正指示を出して再生成でき、案はバージョン管理される。気に入らなければ前の版に戻せる。確定したら次の工程(ワイヤーフレーム)へ自動で進む。「生成して終わり」ではなく、編集者が手綱を握ったまま速くする設計にした。
対象は編集者最大5名、利用は月20回ほど。従来2〜3時間の工程が15分以内になり、10〜15倍の高速化。しかも運用コストは月¥450〜750に収まった[3]。「人手を増やす」のではなく「毎回の判断を道具に畳む」——それが狙いだった。
02設計を先に書き、Phase 0〜5 を1セッションで
速く作れた最大の理由は、勢いではない。先に設計を言葉で固めたことだ。手を動かす前に、仕様・設計・画面・タスク・履歴のドキュメント5点セットを用意し、開発をフェーズに分割した。
そのうえで、初期化(Phase 0)→ 認証・DB(1)→ ナレッジ管理(2)→ オリエン入力・構成案(3)→ ワイヤーフレーム生成(4)→ 仕上げ・テスト(5)を、1セッションで一気通貫に通した。各フェーズで「動く状態」を確かめ、要所だけ人が承認する。言語化がそのまま設計図になり、設計図がそのまま実装の順路になる。
仕上げ(Phase 5)も手を抜かない。全画面にエラー境界とローディング表示、アイコンボタンには読み上げ用ラベル、型チェックと静的解析はエラーゼロ——"とりあえず動く"と"納品できる"の距離を、最初の1セッションで詰めておく。後から品質を足すのは高くつく。最初から作品として整えるほうが、結局は速い。設計を先に書く一手間が、後工程の手戻りを丸ごと消すのだ。
03認証とデータは、"ブラウザに触らせない"
業務ツールは、扱うデータの守りが命だ。認証は専用サービス(+Google連携)に任せ、データベースへのアクセスはすべてサーバー側に限定した。ブラウザから直接DBを触る経路は作らない。
- サーバー専用キーでのみDBアクセス。画面側は自分のIDで絞った結果だけを受け取る。
- 行レベルのアクセス制御はセーフティネットとして全拒否を敷き、アプリ層でも本人のデータだけに絞る(二重の壁)。
- 外部連携トークンは常に発行元から取り直す。これがのちのバグ(後述)を生み、設計の甘さを教えてくれた。
「便利さ」より先に「触れない経路をなくす」。守りを最初に設計に組み込むほど、後から増改築しても崩れない。実際このツールは、本番投入後に出力エンジンを丸ごと差し替える大改修をしたが、認証とデータの土台は一度も触らずに済んだ。変わる部分(出力)と変わらない部分(認証・データ)を最初に分けておく——この線引きが、後の作り直しを安全にする。守りの設計は、堅さだけでなく"変えやすさ"のためでもある。
04AIは、役割で使い分ける
「AIを使う」と一括りにすると、品質もコストもぶれる。このツールでは、モデルを役割で分けた。
- 構成案の生成=高品質モデル:誌面の良し悪しを決める中核なので、上位モデルをストリーミングで使う。
- PDFの解析・メタ抽出=軽量モデル:大量・定型の下処理は、軽くて安いモデルに回す。
この使い分けが、品質を落とさずに月¥450〜750という運用コストを生んだ[2]。「全部いちばん賢いモデル」ではなく、要所に賢さを集中させる。これは、CAGが掲げる「AI実費パススルー(使った分だけ開示)」を成立させる前提でもある。安く回せる構造を作れるから、安さを約束できる。
逆に言えば、ここを雑にやると運用費は簡単に膨らむ。月数千円を見込んでいたものが、モデル選定ひとつで桁が変わる。どの工程にどのモデルを当てるかは、機能ではなく"原価"の設計だ。動くものを作るだけなら誰でも全部を上位モデルで通せばいい。だが「使い続けられる道具」にするには、一回ごとの単価まで設計に含める必要がある。
05ストリーミングは、手で組む
AIの長い出力は、生成され次第どんどん画面に流したい(待ち時間の体感が変わる)。既製の「丸ごとストリーム化」関数もあるが、細かい制御が効かない。そこで出力の差分(delta)を自分で受けて積み上げる方式を手で組んだ。
地味だが、これが効いた。同じ仕組みを「構成案の生成」と「ワイヤーフレームの生成」の両方で再利用できたのだ。一度ちゃんと作った部品は、二度目からタダになる。手戻りを減らすのは、奇抜さではなく、こうした「再利用できる形」への分解だ。
これはAI駆動開発の勘所でもある。AIに任せると、つい毎回ゼロから書かせてしまう。だが本当に速い人は、「これは一度作れば使い回せる部品か」を見抜いて、共通化を先に指示する。構成案もワイヤーフレームも「AIの長い出力を逐次流す」という同じ形だと気づけば、部品は一つで済む。速さは、量で殴ることではなく、構造を見抜くことから来る。
06出力先の限界に当たったら、作り変える
最初のワイヤーフレーム出力は、スライド系のAPIで作っていた。きれいに動いた——が、本番投入後にクライアントから3つのフィードバックが届いた。「見開きは横長で」「細かい文字は要らない、要素ラベルと分量だけ見せて」「画像がスカスカ、実誌に近い量に」。
調べると、使っていたAPIにはテキストの回り込み・斜め配置・要素の重なりが作れないという根本的な限界があった。小手先で粘らず、出力エンジンを画像生成ベースに作り変える判断をした。クライアントから受け取った実誌のサンプルを参照画像として渡し、「実誌に近い密度のラフ」を生成できるようにした。
大事だったのは移行のやり方だ。旧方式を消して一気に入れ替えるのではなく、旧方式はボタンとして残したまま新方式をデフォルトにする段階移行にした。動いているものを壊さず、新しい価値を上に乗せる。「正しい作り直し」は、退路を断つことではなく、退路を残しながら前に出ること。本番で使われているツールほど、この順序が効く。
「動いている」と「相手が欲しい形」は別物。限界に当たったら、粘るのではなく作り変える。ただし、退路は残す。
07派手な機能より、地味な"つまずき"を潰す
本当に時間を使うのは、華やかな機能ではなく、地味な落とし穴だ。このツールでも3つに当たり、どれも気合いでなく仕様とログで潰した。
- 外部トークンの"期限切れキャッシュ":DBに貯めた連携トークンが切れているのに使い回して失敗。→ 常に発行元から取り直すに変更(キャッシュが新鮮さを殺していた)。
- 新しい画像生成APIが既定で無効:本番でいきなり権限エラー。→ 既存の安定APIに即フォールバックし、
TODOコメントで後日切替できるように。 - データ移行のバージョン衝突:同日に2つ作ってキーが重複。→
日付+連番の採番ルールで解決。
共通する教訓は、失敗を「気合いで直す」のではなく「仕様に戻す」こと。原因を次の仕様やログに焼き直すほど、同じ事故は減る。とくに効いたのは最初からエラーをログに出す設計だ。1つ目のバグは、画面には何も出ず処理が静かに止まっていた——握りつぶさずログに吐く一手を入れていたから、原因(古いトークンの再利用)まで一直線で辿れた。派手な機能より、失敗が見える状態を先に作る。これが結局いちばん速い。
08速さの正体は、"型"と"判断の分業"
このツールがくれた一番の価値は、編集者の時間だ。毎号の2〜3時間が15分になり、その分を中身の編集に回せる。だが制作側として一番伝えたいのは、この速さは才能ではなく型から来ているということだ。
1セッションで完走できた要因は、振り返るとシンプルだ。①設計を先に言葉で固めた(仕様・設計・タスク・履歴・指針)②フェーズに割って各段で動かした③一度作った部品(ストリーミング等)を使い回した。奇抜な発明はひとつもない。再現できる手順の積み重ねだけだ。だからこそ、次のツールでも、別の業種でも、同じ速さで作れる。
設計を先に書く。フェーズに割る。AIに実装を一気に通させ、人は評価・設計・検証に集中する。限界に当たったら退路を残して作り変える。失敗は仕様へ戻す。——どれも、CAGがクライアントワークで毎回やっている作法そのものだ。だから、同じ品質に、桁違いに少ないコストとリードタイムでたどり着ける。そして圧縮したコストは、隠さずお客様に返す。次にあなたが「これ、毎回手作業で何時間かけてるんだろう」と思った仕事。まず、言葉にしてみてほしい。
従来の手作業 vs AI駆動ツール。同じ「ワイヤーフレームづくり」を、どう変えたか。
| 観点 | 従来(編集者の手作業) | 電脳技巧集団(AI職人ギルド) |
|---|---|---|
| 1本の所要 | 2〜3時間 | 15分以内(10〜15倍速) |
| 品質の安定 | 担当者の経験に依存 | 過去ナレッジ参照+構成ルールで均す |
| 運用コスト | 人件費(毎号積み上がる) | 月¥450〜750(AI実費・開示) |
| 納期 | — | 設計→本番まで実働1セッション |
| 変更対応 | 毎回やり直し | 出力エンジンごと差し替え可(退路を残す段階移行) |
| 誰が作るか | 外注の都度見積り | 成果物×定価+AI実費パススルー |
※ 「2〜3時間」「15分」「月¥450〜750」「10〜15倍」は本事例の自社記録・想定に基づく目安。顧客・媒体・個人は匿名化したケーススタディ。
出典・脚注
- 技術構成(参考):モダンなWebフレームワーク(App Router)/認証サービス+Google OAuth/マネージドPostgreSQL(RLS・ストレージ付き)/生成AIのAPI(構成案=上位モデル・ストリーミング/下処理=軽量モデル)/スライド・画像生成API/エラー監視。具体の製品名・バージョンは省略。
- 運用コストは構成案=上位モデル・下処理=軽量モデルのモデル使い分けによる本事例の概算(編集者5名・月20回想定)。実費は利用量で変動。
- 「2〜3時間→15分」「月¥450〜750」「Phase 0〜5を1セッション完走」は本事例の自社開発記録・運用想定に基づく目安。発注元・エンドクライアント・媒体名・個人・リポジトリは匿名化している。
その「毎回の手作業」、道具に畳めます。
2〜3時間の繰り返しを、15分に。社内の定型業務こそ、AI駆動の自動化がいちばん効きます。まずは「何に何時間かけているか」を言葉にすることから。
無料で相談する →







