― 怠惰なバックエンド開発者の反省 ―
動的CMS設計
2026年1月、本社に復帰して参加したプロジェクトは「観光コンテンツ管理システム（Pinlime）」でした。過去にある企業へ導入したプロジェクトを基盤に、最新アーキテクチャ上で再構築を進めていました。数多くの観光地リソースを一目で分かりやすく管理するため、JSON構造を柔軟に保存し、UIまで自由に変形できる形で設計が進められていました。
動的CMS設計
「雪岳山」のような自然景観には登山道入口や立入規制期間などのフィールドを、「博物館」のような施設には休館日や営業時間を、「レストラン」にはブレークタイムやビーガンメニューなどを入力できるよう、入力フォームをリアルタイムでレンダリングし、後からデータ構造が変わっても簡単に構造を変更できる教科書的なシステムでした。AIを使って分析してみても、大きな無駄がなく高い評価を得られる設計でした。
使いにくいシステム
開発者として、この構造は明らかに柔軟で魅力的でした。しかし、観光地データを入力するために入力フィールドを定義し、入力フィールドをまとめて入力グループを定義し、特定の種類の観光地カテゴリーに適したコンテンツモデルを定義して観光地にマッピングし、観光地データを入力するようになると、疑問を感じ始めました。
このシステムを自分で設計したため、入力フィールド、グループ、モデルを作成して観光地データを入力する流れを理解していたにもかかわらず、数多くの反復作業や、適切なフィールドを探してモデルを定義する作業にすぐに疲れ果ててしまいました。システムを作った私でさえこれほど疲れるのに、システムを知らない現場のスタッフがこのシステムをうまく使えるのだろうかという疑問が、頭から離れませんでした。
容易に想像できる現場の状況
AI-LLMとの出会い
この時点で私は、他の人たちが皆使っているClaude CodeやCodexすら使えず、かろうじてLLMのウェブサイトでコードや設計に関する知識を尋ね、検討する程度でした。一言で言えば、AI音痴でした。AIエンジニアといえば、自分でモデルを作って学習させ、AlphaGoのような製品を作る人だと思い込み、距離を置いて生きていました。そのため、このシステムを現場で簡単に使えるようにする方法として思いつくのは、ユーザーインターフェースの改善だけでした。
その間に、Pinlimeに「AI旅行作家」機能を追加することが決まりました。この機能はLakeyチームが担当し、私はPinlimeとLakey間のデータパイプライン接続に参加することになりました。Lakeyチームにデータを渡し、生成されたデータを画面に渡せばよい作業でしたが、少し興味を持ち、使いやすいインターフェースの構成を考えるために、より詳しく見ていくことにしました。
AIをシステム構築に活用するのは、予想外に単純な作業でした。GeminiのウェブサイトでLLMに質問するのと、大きく変わりませんでした。実際、多くのAI機能は「プロンプト作成 -> LLM呼び出し -> 結果表示」というレベルで実現されています。
-
旅行作家：観光地データ + エッセイ作成プロンプト + リクエスト = 結果エッセイ
-
多言語翻訳：翻訳対象テキスト + 翻訳プロンプト + リクエスト = 翻訳結果
AI適用の難易度
LLMを使った開発に少し踏み込んでみると、観光地の紹介テキストがあれば、テキストからスキーマに合ったJSON形式の結果を生成することは、何でもない作業でした。すでにコンテンツモデルには、抽出すべき情報が詳細に定義されています。そのため、人が一つひとつフォームに合わせてデータを入力する代わりに、テキスト入力欄へ観光地のテキストを貼り付けるだけで、数秒以内に観光地データが入力フォームへ正確に反映されるのを目の当たりにしました。
ひとまずAI、つまりLLMを利用する方法が分かると、さらに多くのことを構想する段階へ進みました。コンテンツモデルには、必要に応じて特定のフィールドが追加されたり削除されたりします。そして、その変更が行われると、過去のバージョンで作られたコンテンツは、過去のモデル構造を知らなければデータを表示できないため、リビジョンまたはスナップショットという名前で管理していました。LLMを適用する前は、旧バージョンは旧バージョンとして、新バージョンは新バージョンとして表示するだけでした。しかしLLMを適用すれば、旧バージョンのデータを新バージョンのデータへ変換することも、難しくない作業になると予想されます。
手間は少し増えるが、簡単になったコンテンツマイグレーション
AI-Nativeへ開発方式を転換
もちろん、例に挙げたほどLLM/LMMを利用したアプリケーション開発が簡単なわけではありません。従来のプログラミングが「入力->ルール->決められた出力」だとすれば、LLM/LMMを利用した開発は「入力->確率的推論->可変的な出力」であるため、結果をそのまま確定してしまうと問題が発生する可能性が高くなります。ハルシネーションの制御、出力形式の構造化、プロンプトのセキュリティと悪意ある入力の遮断、機密情報の漏洩防止、トークンコストの制御など、従来のプログラミングとは異なる考慮事項が数多くあります。
それでも、従来のソフトウェア開発方式からLLM/LMMベースの開発方式へ転換すべき理由は明確です。従来の方式で解決しようとすると多大なコストと時間がかかったり、実装自体が難しかったりする領域を、LLM/LMMは100%正確な結果ではないとしても、圧倒的な効率で解決してくれるからです。
もしかすると私は、AI-Nativeソフトウェア開発におけるHello Worldの段階に入ったところなのかもしれません。Hello Worldを出力できる程度の知識でこのような文章を残すこと自体、実は恥ずかしくもあります。LLM/LMM APIを呼び出すのは簡単ですが、プロンプトを適切に扱い、従来のソフトウェア工学の手法を用いて完全に制御することは、別次元の問題です。たとえ確率で動くAIであっても、私たちが作る「製品」だけは、常に予測可能な範囲内で信頼できるように動作しなければなりません。そうしてこそ、ユーザーが安心して使えるからです。これを適切に扱うことが、AI時代における私たち開発者の役割だと考えています。
zacca