※本レポートは、2025年9月に開催された発表内容をもとに作成されています。
登壇者はこの方
近藤英明
株式会社はてな
コンテンツ本部 第2グループ ブログチーム
ディレクター
- Web制作会社にて多数のWebサイト / システムに携わる
- SESとして事業会社のWebサービスを担当し、CS領域を担当
- 2023年はてな入社。はてなブログのサービス運用と並行してはてなCMSの開発に携わる
近藤：私は、Web制作会社で多数のWebサイトやシステムに携わった後、SESとして事業会社のWebサービスを担当し、CS領域を担当していました。2023年にはてな入社後、はてなブログのサービス運用と並行してはてなCMSの開発に携わっています。
本日は、技術的な実装の詳細をお話するというよりは、プロダクトの意思決定やPdM（プロダクトマネージャー）としての視点で、どのように課題を乗り越えていったのかについてお話できればと思います。
はじめに
はてなについて
株式会社はてなは2001年創業のインターネット企業です。はてなブログやはてなブックマークといったユーザー参加型サービスを長年運営しており、そこで培った技術やノウハウを活かして、様々な企業向けのサービスを提供しています。
本日の題材：はてなCMS
本日ご紹介する「はてなCMS」も、法人向けに提供しているコンテンツ管理システムです。ノーコードでのページデザインや、直感的な編集・管理機能を特徴としています。コーポレートサイト、オウンドメディア、LP（ランディングページ）、採用サイト、キャンペーンサイト、サービスサイトなど、様々なWebサイトを構築することができます。
本日の題材：Figma to はてなCMS
Figmaプラグイン「Figma to はてなCMS」を利用することで、Figmaで作成したデザインデータをAIが理解し、はてなCMSに自然なコードに変換して反映することができます。また、はてなCMS上での簡単な編集・管理により、サイト運用の効率化を強力に後押しします。今回は、このAI機能を開発する過程で、どのような技術的な壁を乗り越えてきたのかという開発の裏側をお話します。
課題提示
解決したかった課題
Web制作における「デザイン」と「実装」の分断が、解決すべき大きな課題でした。
Figmaで作成したデザインを手作業でコーディングし、CMSへ入稿するプロセスには、以下のような問題が潜んでいます。
- 時間的・人的コスト
- コミュニケーションロス
- 手作業による実装ミス
このような手作業のプロセスには、時間や人件費といった目に見えるコストだけでなく、コミュニケーションの齟齬やちょっとしたミスといった、目に見えない部分でのコストやリスクが潜んでいます。
一連のプロセスをAIで自動化し、Webサイト制作の生産性を向上させることが本機能の目的です。
AI開発は「魔法の呪文」探しではない
一般的に、AI開発というと完璧な指示文「神プロンプト」さえ見つければ全てが解決するというイメージがあるかもしれません。
しかし、今回の経験から言えることは、そこは本質ではないということです。優れたAIプロダクトは「魔法の呪文」ではなく、AIを管理・評価・修正する「仕組み（システム）」によって作られます。
本セッションでは、その「仕組み」をどう構築したか、その意思決定のプロセスを共有できればと思います。
Case Study: Figma to はてなCMS — 私たちが乗り越えた「3つの壁」
デザインと実装の分断をなくすことがプロジェクトの目的でしたが、開発を進める中で、3つの大きな壁にぶつかることになりました。
- 壁①：トークン数の壁
- LLMが一度に出力できる文字数には、構造的な上限があります。長いページになってくると、コードが上から下まできっちり全部出力されないという問題が発生しました。
- 壁②：品質保証の壁
- AIの出力は常に変動します。どうすれば安定した品質を保証できるのかという課題がありました。
- 壁③：実装コストの壁
- 理想的な仕組みを、現実的な開発期間とコストでどう実現するのかという問題がありました。
解決へのアプローチ
課題とアプローチ：根本方針の決定
開発チームは複数の選択肢を検討しましたが、それぞれに課題がありました。
検討した選択肢と不採用の理由
- A案：神プロンプト
- トークン数の壁により構造的に不可能だったため、不採用となりました。
- B案：ルールベースでの変換
- オープンソースではニーズが満たせず、実装コストが非常に高かったため、不採用となりました。ルールを細かく定めるということは、膨大な実装コストがかかることがすぐにわかり、断念せざるを得ませんでした。
結論：Agentic Workflow（AIワークフロー）の採用
複数のAIエージェントが連携するアプローチが、唯一の現実的な解決策でした。
Agentic Workflowとは、最近AI開発の分野で広く使われ始めている、AIエージェントが連携して複雑なタスクをこなしていくアプローチのことを指します。
解決策の心臓部：「自己評価ループ」
AIの品質課題を解決するため、2つの役割を持つAIエージェントが連携する「仕組み」を構築しました。
- Generator（生成担当AI）：まずコードを作るAI
- Evaluator（評価担当AI）：できたコードが「設計図（Figmaのデザイン）」通りかチェックするAI
この2つのAIが対話する「自己評価ループ」が、解決策の心臓部です。
Generatorがコードを作成し、Evaluatorが評価します。評価の結果、不合格であれば一度再生成するチャンスが与えられ、再びGeneratorに戻るという流れになっています。
3つの壁へのアプローチ
①トークン数の壁：Generatorの工夫
課題：AIは一度に長い文章を書くのが苦手
解決策：AIとの「対話」を自動化する仕組みを作る
一度にすべてを書かせるのではなく、対話しながら少しずつ生成させるアプローチに舵を切りました。
このAIとの対話を自動化する技術が「Tool Calling」です。AIがシステムの「ツール（道具）」を能動的に呼び出すことで、複雑な連携を可能にします。
具体的には、システムからAIに設計図を渡してコードを書いてもらうよう依頼します。AIは書けるところまでコードを書き、最後に「まだ続きがあります」という連絡をシステムに送ります。システムはそれを受け取ると、一度生成したものを添えて、再度続きを書くよう指示を出します。この対話を、AI側が完了と判断するまで繰り返すことで、物理的な文章量の限界を超えることができました。
②品質保証の壁：Evaluatorの信頼性
課題：AIの評価は、人間の文章のように曖昧で気まぐれではないか？
解決策：AIを「公平な審査員」として育てるための「3つのルール」を課した
評価専用のAIに対して、どれだけ公平な審査員として機能するかを考え、3つの厳格なルールを課しました。
- ルール①：役割を与える（ペルソナ指定）
- 「あなたは公平な審査員です」と、具体的な役割を任命することで、評価の視点をきっちりと固定します。
- ルール②：結論を急がせず、慎重に考えさせる（思考の連鎖）
- 「結論に飛びつかず、ステップバイステップで論理的に考えなさい」と指示し、評価の精度を高めます。
- ルール③：厳格なフォーマットで報告させる（JSON形式）
- 自由な文章ではなく、機械が解釈できる厳密な形式で評価結果を提出させます。
この3つのルールで、AIの評価から「曖昧さ」と「気まぐれ」を排除しました。
③実装コストの壁：現実的な側面
コストへの対策
- ループ回数の制限：自己評価ループは最大1回に制限し、無限ループによるコスト増大を防止しました。
- キャッシュ活用：一度AIに渡した長文の指示はキャッシュし、再利用することでAPIコールを最適化しました。
- 戦略的トレードオフ：実装が複雑で時間がかかる手法（Reflexion）より、AIコストは高くても実装が容易な手法（Reflection）を選択し、開発期間を短縮しました。費用よりもAIに関する実装コストを優先した判断です。
失敗がもたらした進化
このワークフロー全体が、最初の「神プロンプト」アプローチが完全に失敗した経験から生まれています。そもそもAIでやるのかというところからスタートしており、まさかこんな複雑なAIのシステムを構築することになるとは最初は全く思っていませんでした。この失敗した経験が、ここまでの検討につながったと言えます。
まとめ
結論：AIプロダクト開発は「意思決定」の連続である
今回の経験から、AIプロダクト開発は、単に優れた技術を選ぶということではなく、技術的な制約やビジネスとしての要求が常に両側にある中で、トレードオフを判断して意思決定を下していくプロセスそのものであることがわかりました。
本当の価値は、AIモデルそのものではなく、AIをどう組み合わせていくのか、そしてどう設計してプロダクトまで落とし込んでいくのか、そういったものをどう評価してどう運用していくのかというシステム全体の設計にあると言えます。
▼▼ ぜひ他登壇者の発表レポートもご覧ください！
