セミナーレポート#01 何を作るか、何を作らないか - AI時代の境界設計【Claude Code & Codex 実装現場ノート】

AIで何でも作れるようになった。Claude Code、Codex、そしてCodex App Serverの登場によって、個人サブスクの延長線上で業務アプリの試作までが射程に入る時代になった。

しかし、いま実装の現場で起きているのは、別の問題だ。「動いた」AIアプリと、「回る」AIサービスのあいだに、まだ大きな設計の塊が横たわっている。プロンプトが書けるからといって、組織で運用できるとは限らない。試作できるからといって、社外のサービスにできるとは限らない。

本シリーズは、その境界線を歩く実装現場のノートだ。第1回となる本記事では、すべての出発点となる「何を作るか／何を作らないか」、つまり境界の設計を扱う。

「動いた」と「回る」のあいだ

個人で試している間、AIアプリは思いつきで動かしてもよかった。プロンプトを書く、コードはローカルに置く、共有は思いつき、セキュリティとコストは「気にしてはいる」。自分しか触らないから、暴走してもPCで止まる。

ところが、「使ってもらう」「組織で回す」となった瞬間、前提が変わる。

• 誰が、何のために、いつまで使うか
• 入れていい情報の線引きが先に要る
• コストと利用量を、誰もが見える形にする
• 暴走したとき、責任を取れる構造になっているか

この変化は、技術の追加では解決しない。設計思想そのものを切り替える必要がある。そして切り替えの最初に来るのが、本記事で扱う「境界の設計」である。

「使われる場面」から逆算する - 使用駆動開発

AIアプリを作ろうとして最初につまずくのは、機能リストから設計を始めるパターンだ。

「自動要約機能」「タグ付け機能」「レポート生成機能」 - 箇条書きが伸びるほど、開発は終わらなくなる。リストには優先順位がつかず、何から手をつけるかが定まらない。

代わりに使えるのが、使用駆動開発という発想だ。機能ではなく、使われる場面から逆算して設計する。具体的には、3つの問いを立てる。

• WHO（誰が触るか） - 肩書きではなく業務の名前で答える。「商談直後の営業」「面接前夜の人事」のように
• WHEN（いつ触るか） - 週次定例ではなく、その瞬間。「資料を送る前の5分」など
• OUTCOME（何が出来上がるか） - ファイルか、メッセージか、判断か。最後に手元に残るものを決める

この3つが一文で書ければ、もう試作できる。たとえば「商談直後の営業が、上長への報告ドラフトを5分で得る」。これが書けないものは、まだ作る段階ではない。

「やらないこと」を決める - 機能+1、運用×2

使用駆動で一つの場面を定めたら、次に来るのが「やらないこと」の定義だ。

ここでとても重要な経験則がある。機能を1つ足すたびに、運用は2乗で重くなる。テスト、問い合わせ、教育、障害対応、変更履歴の追跡。これらは機能の数の二乗のオーダーで膨らんでいく。

AIアプリは、設計者が止めなければ無限に伸びる。プロンプトの書き方ひとつで新しい用途が開けるからだ。「思いついたから作る」を許容したサービスは、半年後に運用が破壊される。

だから初期に決めるのは、入れる機能ではなく、入れない機能だ。境界線が、そのサービスの個性になる。何を断ったかが、ブランドとして残る。

これは後段（シリーズ第3回）で扱う「AIヴァンパイア」問題への伏線でもある。便利だからといってすべてを引き受ければ、AI自身に飲み込まれる。

AIに任せない9つの仕事

境界の設計には、もう一段の解像度が要る。AIそのものに「向いていない仕事」を知っておくことだ。万能ではないと知っている人ほど、AIを使い倒せる。

2026年5月時点で、私たちが「AIには任せない」と整理している9つを挙げる。

このリストは絶対ではなく、半年で変わる項目もある。しかし「ここはAIに任せない」と組織で合意することが、サービスの輪郭と責任の所在を明確にする。

自作と既存SaaS、どこに線を引くか

境界の最後のレイヤーは、「そもそもAIで内製すべきかどうか」だ。「AIで開発すればよくない？」という社内の声に答えるための補助線を引いておく。

判断軸は、以下の5つに整理できる。

たとえば、ShopifyのようなECプラットフォームを自社で内製するのは絶対に割に合わない。プラットフォームレイヤーは既存SaaSが進化のスピードで圧倒する。逆に、自社固有の商談プロセスや、ブランド独自の顧客接点はAIで内製する価値がある。

特に、Shopifyが2026年に正式リリースしたAgentic Storefrontsや、Universal Commerce Protocol（UCP）に代表されるAgentic Commerceの潮流は、まさにこの線引きの再設計を迫っている。コマースのプラットフォーム層は既存SaaSが進化し続け、その上に乗る顧客接点・ブランド体験は内製で差別化する余地が広がる。プラットフォームに乗るか、その上で何を内製するか。両者を切り分ける目利きが、これからの経営判断になる。

ここまで、4つのレベルで境界を引いてきた。

• 「動いた」と「回る」を分ける
• 使用駆動で場面を定める
• 「やらないこと」を明示する
• AIに任せない領域を共有する
• 自作と既存SaaSの線を引く

これらすべてに共通する出発点が、一つある。設計はテキストから始まる、という事実だ。

人間は、ホワイトボードの絵、図、空気で詰めながら進められる。誰かが察してくれるし、誰かが翻訳してくれる。しかしAIは違う。トランスフォーマーアーキテクチャは、言語化されていないものを扱えない。口頭・図・空気は入力にならない。

つまり、最初にテキストをまとめた人が、一番速く作る。

箇条書きでいい、まずテキストに落とす。これが、AI時代の境界設計の出発点であり、終着点でもある。

次回 #02「全社で使うための4レイヤー - セキュリティ・ナレッジ・APIキー戦略」では、境界の引かれたAIアプリを、組織でどう運用するかに踏み込む。アクセス制御、ガードレール、APIキーの正しい持ち方、コスト可視化、組織展開──情シスと経営層がぶつかる現実的な4つの壁を扱う。

参考

• Anthropic「Claude Code Documentation」 -  Claude Codeの公式ドキュメント。
  https://docs.claude.com/
• Shopify Engineering「Building the Universal Commerce Protocol」 -  Agentic Commerce / Agentic Storefronts の技術背景。
• OpenAI「Codex Documentation」 -  Codex / Codex App Server の公式情報。