Algomatic Tech Blog

Algomaticの開発チームによる Tech Blog です

コンピュータビジョンの最前線 ICCV2025論文紹介

こんにちは、Algomatic AXの大塚(@ootsuka_techs)です。

画像・動画処理の国際カンファレンス ICCV 2025 から、興味深かった論文をいくつか紹介していきます。

取り上げる論文

  1. Inpaint4Drag - ドラッグ操作による画像編集の高速化
  2. V2M4 - 単一動画から4Dアニメーションを生成
  3. LayerAnimate - レイヤー単位で制御可能なAIアニメーション
  4. Web-SSL - 言語ラベルなしの視覚表現学習
  5. ADCD-Net - 文書画像の偽造検出技術

1. Inpaint4Drag: ドラッグ操作で画像を自在に編集する超高速技術

概要

Inpaint4Drag は「この物体を右に動かしたい」「顔の向きを変えたい」といった画像編集を、物理学ベースのアプローチで解決した技術です。

DragGANやDragDiffusionがドラッグ操作を実現しましたが、処理速度の遅さがネックでした。Inpaint4Dragはリアルタイムでのドラッグ編集を可能にし、この問題を解決しました。

この技術で面白いと思った点は、弾性物体変形の物理現象を画像編集に応用したアプローチです。物理法則に基づいた変形により、ユーザーの意図を反映した結果が得られます。

技術的アプローチ

Inpaint4Dragは、弾性物体変形をヒントにしたアプローチを使っています。画像領域を変形可能な材料として扱い、ユーザー操作下で形状を維持する設計です。

処理は「双方向ワーピング」と「画像修復」の2段階で構成されています。フォワードワーピングで変形後の輪郭を推定してから、バックワードマッピングでカバレッジを補完します。この変形領域をインペインティングモデルで補修し、512×512解像度の画像をリアルタイムプレビュー0.01秒、最終処理0.3秒で処理します。

応用例

画像修復モデルと組み合わせることで、インペインティング技術を活用した編集ワークフローを構築可能です。

ポートレートの姿勢調整、商品画像のレイアウト変更、背景が隠れている場合の編集など、幅広いケースで生成結果が得られます。クリエイティブ制作だけでなく、EC運用などビジネス用途での活用も見込まれます。

参考リンク


2. V2M4: 単一動画から使える4Dアニメーションを自動生成

概要

V2M4 は、スマートフォンで撮影した1本の動画から、UnityやUnreal Engineで使える4Dメッシュアニメーションを自動生成する技術です。

ゲーム開発や映像制作における3Dキャラクターのアニメーション生成は、時間とコストのかかる作業です。モーションキャプチャー設備のコストは高く、手作業でのモデリングとアニメーション制作には数週間から数ヶ月かかることもあります。V2M4は動画撮影だけで4Dアニメーションを生成できる手軽さで、制作現場のハードルを下げています。

注目する点は、3Dアニメーション生成をEnd-to-Endで解決したことです。これまでは複数のソフトウェアを使い分ける必要がありましたが、動画撮影からゲームエンジン対応ファイルまで一気通貫で処理できるようになりました。

技術的アプローチ

V2M4は他の手法と異なり、ネイティブな3Dメッシュ生成モデルを使用しています。マルチビュー画像生成に頼る手法と比べ、トポロジーの統一性が保たれます。

処理は5段階のワークフローで構成されています。カメラサーチとメッシュリポジング→条件埋め込み最適化→ペアワイズメッシュレジストレーション→グローバルテクスチャマップ最適化→キーフレーム補間の流れです。これによりメッシュポーズの不正確性、外観のミスアライン、ジオメトリとテクスチャマップの不一貫性といった課題を解決しています。

応用例

インディーゲーム制作でモーションキャプチャーが難しい場合や、短期間でコンセプト映像を作りたい場合に有用です。スマートフォン撮影素材からデジタルツインを生成する用途にも使えます。

現場での撮影とアニメーション制作を一体化することで、プロトタイピングの高速化やキャラクターアニメーションのバリエーション生成も期待されます。

参考リンク


3. LayerAnimate: レイヤー単位で制御可能なAIアニメーション生成

概要

LayerAnimate は、層ベースの制作スタイルをAI動画生成に持ち込んだ研究です。

アニメーション制作では、キャラクター・背景・エフェクトなどをレイヤーごとに管理するのが一般的です。生成系AIで同じレベルの制御性を確保するのは難しい問題でしたが、LayerAnimateはレイヤー単位での制御を実現しました。

注目する点は、プロの制作現場で使われるレイヤー構造をAIに採用したことです。制作ワークフローとの親和性が高く、プロのアニメーターが使いやすい設計です。

技術的アプローチ

LayerAnimateは動画拡散モデルに「層認識アーキテクチャ」を組み込んでいます。各レイヤーに対して個別の条件を加える柔軟な構成で、モーションスコア(動きの強度)、軌跡(移動パス)、スケッチ(形状や位置)などの制御を組み合わせられます。

プロフェッショナルアニメーション資産の商業的機密性によるデータ不足に対処するため、自動要素セグメンテーションと動きベースの階層的マージングからなるデータキュレーションパイプラインが作られています。これによりモーションスコアが時間的に一定に保たれるキュレーション済みレイヤーマスクを生成します。

応用例

プロのアニメーターならDCCツールに近い感覚で生成映像を編集可能です。初心者もレイヤー単位で意図を反映しやすくなります。

キャラクターと背景の差し替え、エフェクトだけの再生成、アニメーションスタイルのバリエーション作成といった、制作パイプラインの柔軟性が求められる場面で有効です。

参考リンク


4. Web-SSL: 言語を使わない視覚表現学習の大規模化

概要

Meta AIが発表する Web-SSL は、言語ラベルなしでもCLIP級の視覚表現を獲得できることを示した研究です。

OpenAIのCLIP以降、画像とテキストを組み合わせた視覚言語モデルが主流になっていました。教師データを用いた学習が高性能に必須だと考えられてきましたが、Web-SSLは大規模データとモデルスケーリングによってこの前提を問い直しています。

この研究で興味深いのは、テキストアノテーションの用意が難しい領域での可能性を広げる点です。産業用途や特殊ドメインなど、言語リソースが限られた分野でも高品質な視覚モデルを作れる道が開かれました。

技術的アプローチ

Web-SSLは3つの要素を組み合わせた研究です。MetaCLIPデータセット(20億画像)を使用し、Vision Transformerを10億〜70億パラメータにスケール、16種類のVQAベンチマークで評価しています。評価には固定されたビジョンエンコーダーと軽量MLPアダプター、Llama-3 8B言語モデルを使用します。

Web-DINOモデルは10億→70億パラメータで+4.9%の一貫した改善を示し、70億パラメータで平均VQA性能53.9%を達成しました。一方CLIPは性能が飽和します。データを10億→80億サンプルへ拡張した場合、OCR・グラフ理解で26.8%→39.3%の性能改善が確認されています。ImageNet-1kでの学習では規模による改善がほぼ見られない(-0.1%)のに対し、MetaCLIPでは+2.7%の向上が見られ、ウェブスケールの多様性が効果的なスケーリングに必須であることが示されました。

応用例

テキストアノテーションが用意しづらい領域や多言語環境で有用です。OCRやグラフ理解など文字情報を含むタスクでも、CLIP同等以上の性能が出ています。

言語リソースが限られた産業領域でのモニタリング、自前データでの自己教師あり学習、プライバシー制約でテキストラベルを付けられないケースでの活用が考えられます。

参考リンク


5. ADCD-Net: 文書画像の偽造を検出する技術

概要

ADCD-Net は文書画像の偽造箇所を特定する技術です。

契約書や請求書などの文書画像の不正な書き換えが容易になった現在、これはセキュリティリスクとなっています。ADCD-NetはRGB画像とDCT(離散コサイン変換)特徴量を組み合わせたアプローチでこの課題に対応します。

この技術が持つ意義は、AI生成コンテンツが普及する中で今後必要になる、AIへの信頼性を保証する研究である点です。生成技術だけでなく検証技術も発展させることで、AI時代のエコシステムが作られていくと考えられます。

技術的アプローチ

ADCD-Netは2つのモジュールを中心に設計されています。

適応的DCT特徴量 DCT変換は画像の圧縮の跡を検出するのに有効ですが、リサイズやトリミングといった処理によるブロックのズレに敏感でした。ADCD-Netは予測されたアライメントスコアに基づいてDCT特徴量の影響を調整し、ズレへの耐性を向上させています。

階層的内容分離 文書画像にはテキスト領域と背景領域が混ざっています。この特性の違いが偽造検出の精度を低下させる原因になっていました。ADCD-Netは階層的な内容分離アプローチを使い、位置特定性能を向上させています。

結果として未改ざん領域の特徴を学習して基準パターンを作り、位置特定精度とロバスト性の両面を向上させました。実験結果では、5種類のノイズに対して他の手法を平均20.79%上回る性能を示しました。

応用例

文書の真正性検証は、法的手続き、金融取引、本人確認(KYC)、保険金請求など多くの現場で求められています。

OCRや文書管理システムに組み込めば、提出書類のスクリーニングや改ざんアラートの発報に使えます。デジタル文書が増え続ける中、検証技術の重要性は高まっていくと考えられます。

参考リンク


まとめ

ICCV 2025で発表される本記事で紹介した5つの論文は、コンピュータビジョン研究が創造性の拡張と社会的信頼の確保、この両軸で進化していることを示しています。

リアルタイムでの画像編集、レイヤー単位でのアニメーション制御、スマートフォン動画からの4D生成といった技術が、制作工程の効率化と表現の自由度向上を実現しています。これまで設備や専門知識が必要だった作業が、より多くの人に開かれつつあります。言語ラベルなしでの視覚表現学習は、これまでの前提を問い直し、学習パラダイムの可能性を示しました。

デジタル文書の偽造検出技術は、AIによるコンテンツ生成が進む中で増大する「真正性の検証」に応えるものです。生成と検証、この両輪が発展することで、AI時代のエコシステムが構築されていきます。

ICCV 2025は、コンピュータビジョンが研究段階から実用段階へ加速する転換点になるかもしれません。


最後にAlgomaticでは一緒に働くメンバーを募集しています! 以下よりお気軽にカジュアル面談をお申し込みいただけると幸いです!

jobs.algomatic.jp


AIエージェントを支える技術: コンテキストエンジニアリングの現在地

はじめに

こんにちは。Algomatic AI Transformation(AX) のsergicalsix(@sergicalsix)です。

本記事では大規模言語モデル(LLM)を用いたアプリケーションないしAIエージェントの構築において切っても切り離せない「コンテキストエンジニアリング」について2025年10月時点での知見を備忘録としてまとめます。

コンテキストエンジニアリングとは

コンテキストエンジニアリングとは、LLM に与える情報(コンテキスト)を制御する技術です。

コンテキストエンジニアリングはよくプロンプトエンジニアリングと対比されます。

プロンプトエンジニアリングとコンテキストエンジニアリング (Effective context engineering for AI agents)

プロンプトエンジニアリングはあくまで特定のタスクに特化したエンジニアリング手法であるのに対して、コンテキストエンジニアリングは複数回の推論、反復的な推論など、より長い時間軸で動作する処理を対象とするエンジニアリング手法です。

また適切な情報を取得してプロンプトに注入するといったRAGの機構も広くコンテキストエンジニアリングに属していると言えます。

コンテキストエンジニアリングは技術的に非常に広い領域にまたがっていると言えます。

コンテキストエンジニアリングの全体像 (The New Skill in AI is Not Prompting, It's Context Engineering)

www.philschmid.de

コンテキストエンジニアリングの重要性

コンテキストエンジニアリングが重要である理由は、LLMが処理可能なコンテキストの量が限られており、コンテキストの品質でシステムの出力の品質が大きく変わるからです。

前者はContext Rotという現象で知られており、一般的にコンテキスト量を増やすほどコンテキストの中から回答に有効な情報(Needleと言ったりします)を抽出/活用できなくなる傾向が高くなります。

この現象はモデルで設定されている最大コンテキスト長よりも短い範囲で発生し、モデルには最大コンテキスト長よりも短い有効コンテキスト長(effective context length)があると言えます。

research.trychroma.com

余談で少し前に発表されたLost in the Middleといった現象もContext Rotと大きく性質は同じであるといえます。

Lost in the Middle: How Language Models Use Long Contexts - ACL Anthology

ここで重要なことはモデルが取り扱えることができる情報は有限であり、モデルには必要な情報のみを入力すべきであるということです。

コンテキストエンジニアリングの手法

コンテキストエンジニアリングは大きく以下3つから構成されます。

  1. Context Retrieval & Generation

  2. Context Processing

  3. Context Management

個々の詳細手法は以下をご覧ください。

コンテキストエンジニアリングの手法 (Figure 1:コンテキストエンジニアリングの全体像の一部)

Context Retrieval & Generation(コンテキスト取得 & 生成)

Context Retrieval & GenerationではLLMがタスクを遂行するために必要な情報を取得・生成します。

こういった今必要な情報を取得して プロンプトに入れるという考えはjust in timeなアプローチと言われます。

メモリ・外部データベースからの情報の取得(ex. RAG)やユーザークエリの書き換え、コンテキストの生成(ex. HyDE, Self-RAG)などが該当します。

Context Processing(コンテキスト処理)

取得したコンテキストをそのまま使うと冗長であったり、ノイズが多いため、使える状態に加工する必要があります。

RankingやFilteringによる並べ替えと除去のほか、Claude Codeなどで見られるSummarization(要約)やCompression(圧縮)などが該当します。

特に要約した情報の活用はRAGとの相性が良いことでも知られており(ex. FG-RAG)、コンテキストエンジニアリングでも有効です。

またノイズが多いデータについては複数のソースを統合して整合性を高めるContext Fusion/Aggregationといった手法が有効です。

またAIシステムのレイテンシやコストなどを考えたとき、KVキャッシュを上手く使うことが重要になってきます。

そこでKVキャッシュをうまく使うためにコンテキストを入れ替えたり、削除しないといったテクニックが有効です。

KVキャッシュのヒット率 (Context Engineering for AI Agents: Lessons from Building Manus)

上記の分類だとシステムプロンプト等のプロンプトエンジニアリングもContext Processingに該当します。

システムプロンプトは曖昧すぎず、専門的すぎないバランスの取れたプロンプトが良いとされています。

システムプロンプトの品質について (Effective context engineering for AI agents)

Few-shotプロンプティングではコンテキストを均一にせず、多様性を高めることが推奨されています。

Few-shotプロンプティングのテクニック (Context Engineering for AI Agents: Lessons from Building Manus)

Context Management(コンテキスト管理)

一度獲得したコンテキストを次回以降に活かすためにコンテキストの管理は重要です。

コンテキストの管理は大きくセッション単位で記憶しておくShort-term Contextと永続的に保持しておくLong-term Memoryの2種類が存在します。また一部のコンテキストは状況に応じて動的に更新されます(Dynamic Context Updating)。

さらにShort-term ContextはScratchpadとStateに分類されます。

コンテキストエンジニアリングのカテゴリとコンテキストの管理方法(図の赤枠部分) (Context Engineering)

ここでいうScratchpadはClaude CodeでいうところのTODO.mdやNOTES.mdなどに該当します。こういったファイルに残すという考え方はManusの知見においても再現性を考慮すると文脈で紹介されています。

コンテキストとしてファイルシステム活用 (Context Engineering for AI Agents: Lessons from Building Manus)

またエージェントの失敗をコンテキストに残しておくといった知見も紹介されています。

失敗をコンテキストに保持 (Context Engineering for AI Agents: Lessons from Building Manus)

余談ですが、弊社で開発しているAIエージェントでも過去の失敗ログをコンテキストに注入することで同一の失敗をしづらくなり、安定性が高まっているのを実感しています。

またマルチエージェントにおけるコンテキストは複数のAIエージェントが共有する知識・記憶・状態の整合性を保つことが重要になります。エージェント間でのコンテキストの同期(Context Synchronization)は必須であり、要約/圧縮情報の共有(Context Summarization for Exchange)や共通のDBへの情報保存(Shared Context Repository)などの方法が有効です。

マルチエージェント間におけるコンテキストの共有 Don’t Build Multi-Agents

おわりに

いかがだったでしょうか。

コンテキストエンジニアリングについて、少しでも情報の整理に役立てば幸いです。


最後にAlgomaticでは一緒に働くメンバーを募集しています!

以下よりお気軽にカジュアル面談をお申し込みいただけると幸いです!

jobs.algomatic.jp

参考文献

www.anthropic.com

cognition.ai

manus.im

arxiv.org

仕様書がコードを生む時代:話題のSDDを試してみた

こんにちは、Algomatic AXの大塚(@ootsuka_techs)です。

本記事では、いま話題の仕様駆動開発(Spec Driven Development; SDD)を調べ、社内で試した学びをまとめます。 今回は以下の4つのツールを使用し、それぞれの特徴や使い勝手を詳しく検証しました。

比較した結果は以下の通りです。

機能比較表

機能 Kiro Spec Kit spec-workflow-mcp cc-sdd
日本語対応
承認フロー
プロジェクトガバナンス
IDE統合 ○(専用IDE)
オープンソース ×
エンタープライズ対応
学習コスト
カスタマイズ性

以降は仕様駆動開発(Spec Driven Development; SDD)とそのツールについて実際にご紹介します。

Spec Driven Developmentとは?

ソフトウェア開発の世界では、アジャイル開発、テスト駆動開発(TDD)、振る舞い駆動開発(BDD)など、数多くの開発手法が提案されてきました。 その中で近年注目を集めているのが Spec-Driven Development(SDD/仕様駆動開発)です。

名前の通り「仕様(specification)」を中心に据え、設計・実装・テスト・ドキュメントすべてを仕様から逆算して進めていくスタイルです。 従来の開発では実装が先行して仕様が後付けになることも多かったのですが、SDDでは仕様を最初に固め、そこから一貫性を持って開発を進めていきます。

今回は、この仕様駆動開発を実践するための4つのツールを使い比べ、それぞれの強みと課題を探ってみました。

1. AWS Kiro - エンタープライズ向けの本格的なSDD環境

Kiroの概要と設計思想

最近、「Vibe Coding」と呼ばれるスタイルが話題になっています。 これは、AIを使って対話形式でコードを書いたりアイデアを形にする方法で、自由でスピーディーな開発が可能になります。 しかしその一方で、生成されたコードの「何を前提にしているか」が曖昧になったり、保守性や品質に不安が残るという声もあります。

そんな中で登場したのが、Amazonの「Kiro」というAI統合開発環境(IDE)です。 これはVibe Codingの手軽さに加えて、仕様をしっかり定めてから設計し、その上でタスクを洗い出していくという「仕様駆動開発(Spec-Driven Development)」を前面に押し出しています。 曖昧さを排除してチーム開発や大規模開発でも整合性を保てるよう設計されているのが特徴です。

Kiroのワークフローと3つのステップ

Kiroの基本的なワークフローについて説明すると、3つのステップで構成されています。

  1. 要求定義(requirements.md) まず「誰が」「何を」「なぜ」求めているのかを明確にします。 ステークホルダーの期待値を言語化し、機能要件と非機能要件を整理します。

  2. 設計(design.md) アーキテクチャ構成やモジュール設計、データモデルなど、どう設計するかをAIと共に設計していきます。 技術選定の根拠も含めて文書化されます。

  3. タスク化(tasks.md) 設計した内容を実装可能な細かいタスクに分解し、進捗を管理できる形にします。 各タスクには優先度や依存関係も含まれます。

Agent HooksとAgent Steering

技術面では、Kiroには「Agent Hooks」という機能があり、ファイルの保存などのイベントをきっかけにテスト実行やドキュメント更新など定型的な作業を自動化できるようになっています。 例えば、コードを保存するたびに自動でユニットテストが走り、カバレッジレポートが更新される、といった仕組みを簡単に構築できます。

kiro.dev

さらに「Agent Steering」という仕組みで、プロジェクト全体の方針(コーディング規約、使用技術、設計原則など)をあらかじめ指示ファイルで定義し、AIにその指示を守らせることができます。
これにより、生成されるコードの一貫性が保たれやすくなり、チーム開発において特に重要な「コードの統一性」が実現されます。

kiro.dev

実際に使ってみた印象では、このAgent Steeringの効果は想像以上でした。特にチーム開発において、AIが生成するコードの品質や一貫性を保つ仕組みとして非常に有効だと感じました。

Kiroの課題と注意点

技術的な制約としては、プレビュー版であるため動作の遅さや未完成な部分、データプライバシーの懸念などが指摘されています。
日本語対応が不十分なため、英語以外で使用した場合に意図しない挙動をする可能性があります。
また、AWS環境への依存度が高いため、他のクラウドプロバイダーやオンプレミス環境での利用には制約があります。

Kiro」は、AIによるコード生成だけでなく、仕様→設計→実装という流れをきちんと踏むことで開発の透明性・保守性を高めようというコンセプトを感じました。
特にチーム開発や企業での利用を想定した場合、ドキュメントによって仕様の統一性が高まり、その結果としてチーム開発のスピード向上につながると感じました。

2. GitHub Spec Kit - シンプルで直感的なSDDツール

Spec Kitの基本コンセプト

Spec Kitは、仕様を中心にしてソフトウェアを作る新しい開発スタイルを支援するツールです。
GitHubが提供するこのツールの最大の特徴は、そのシンプルさと直感的な操作性にあります。
従来のやり方ではコードを書いて初めて成果が見えるものでしたが、この仕組みでは「仕様そのものが動き、コードを生み出す」ことができます。
開発者は「何を、なぜ作るのか」に集中でき、実装の詳細は後から仕様に沿って補われていきます。

実践的な使い方とコマンド体系

実際の操作はシンプルです。
プロジェクトの初期化には specify init を使います。
AIアシスタントの指定や、PowerShell版かbash/zsh版スクリプトの選択ができます。
カレントディレクトリに作りたい場合は --here 、Git初期化を省略したい場合は --no-git を使用します。

次に仕様を記述します。
/specify コマンドで「どんなアプリを作りたいか」を言葉で表現します。
このとき大切なのは「どんな技術を使うか」ではなく「どういう機能を持たせたいか」という意図です。
例えば「ユーザーがタスクを管理できるWebアプリケーション」といった高レベルの要求から始めることができます。

技術計画とタスク分解

仕様をもとに、/plan コマンドで技術的な計画を立てます。
例えば「Viteを使ってできるだけライブラリを減らし、HTML・CSS・JavaScriptでシンプルに実装する」などと記述します。
この段階で、フレームワークの選定やアーキテクチャの概要が決まります。
Spec Kitの優れた点は、技術選定の理由も含めて文書化される点で、後から「なぜこの技術を選んだのか」を振り返ることができます。

そして実際の開発を進める段階になると、/tasks コマンドを使って仕様を細かなタスクに分解します。
これにより「まずデータベースを準備する」「次にUIを整える」といった具体的な進め方が見えてきます。
各タスクには見積もり時間や依存関係も設定でき、プロジェクト管理ツールとの連携も容易です。

環境チェックと依存関係管理

環境に必要な依存関係が揃っているかを確認したい場合は、specify check でツールの有無をチェックできます。
Node.jsのバージョンやnpmパッケージの存在確認、必要な環境変数の設定状況などを自動的に検証し、不足している要素があれば具体的な対処法を提示してくれます。

仕様の定義からタスク分解までを一貫して行うことで、アイデアを素早く実際のアプリケーションに変換できることがわかりました。
Claude Code等と組み合わせることでコードの解釈や生成もスムーズになり、試行錯誤を繰り返しながら仕様を磨き上げることが可能になります。

constitutionコマンドによるプロジェクトガバナンス

Spec Kitの特に注目すべき機能として、/constitutionコマンドがあります。 これは、プロジェクトの根本的な仕様や開発ガイドラインを作成・更新するための機能で、開発チーム全体が共有すべき「プロジェクトのルール」を明文化できます。

この機能の優れた点は、単なる文書管理にとどまらず、以下のような高度な機能を提供していることです:

  • セマンティックバージョニング対応:ルールの更新にMAJOR/MINOR/PATCHのバージョン管理を導入
  • 包括的な検証プロセス:曖昧な表現の排除、日付の統一、宣言的な記述の確保
  • 依存関係の自動同期:ルールを更新すると関連テンプレートやドキュメントが自動同期
  • 同期影響レポート:変更による影響範囲を明確に把握可能

実際に使ってみると、この機能によってプロジェクトの「なぜそう決めたのか」という根拠を体系的に管理できるようになりました。 特にチーム開発において、新しいメンバーが参加した際の学習教材や、技術選定の記録として非常に有効です。

Spec Kitは、ゼロからの開発、既存システムの改善など、さまざまな場面で活用できる柔軟な開発ツールです。 constitutionコマンドのような機能により、単なる仕様管理ツールから「プロジェクトのガバナンス」まで含めた包括的な開発支援ツールとなっています。 個人的な印象としては、特にスタートアップや小規模チームでの利用に適しており、素早いプロトタイピングと仕様の可視化を同時に実現できる点が魅力的だと感じました。

3. spec-workflow-mcp - 堅牢な承認フローを持つSDDフレームワーク

実際に使ってみた第一印象

最初に感じたのは「流れがしっかりしている」ということでした。
spec-workflow-mcpは、Model Context Protocol(MCP)を活用したSDDツールで、各フェーズで明確な承認プロセスが組み込まれているのが特徴です。

プロジェクトを始めると、まず requirements.md が生成されて「どんな機能が必要か」「非機能要件は何か」といった要件定義が文章化されます。
AIが細かく拾ってくれるため、ざっくりした指示がきちんとした要件リストになります。
例えば「ToDoアプリを作りたい」という簡単な要求から、「タスクの優先度設定」「カテゴリ分類」「期限管理」「検索機能」といった詳細な機能要件を自動的に導き出してくれます。

段階的な承認プロセス

次のステップでは設計に進みます。
design.md が用意されて、アーキテクチャやデータ構造が文章化され、それをブラウザのダッシュボード上で確認・承認できます。
ここで承認ボタンを押すと次の段階に進む仕掛けになっていて、自分が「OK」を出さない限り勝手に進まないのは安心感がありました。

この承認プロセスは単なるゲートではなく、各段階での品質を保証する仕組みとして機能します。
要件定義の段階で不明瞭な部分があれば、AIが質問を投げかけてきて、より詳細な仕様を固めていきます。
設計段階では、技術的な実現可能性やパフォーマンスへの影響なども考慮され、必要に応じて代替案が提示されることもあります。

タスク分解と実装の自動化

設計を通過すると tasks.md が出てきて、実装用のタスクに分解されます。
実際にToDoアプリを作らせてみると、単純な追加や削除だけでなく、検索やフィルタリングまで盛り込まれていて、設計通りに動くものができました。

各タスクには以下のような情報が含まれます:

  • タスクの概要と目的
  • 実装の詳細手順
  • 必要な依存関係
  • 推定作業時間
  • テストケースの概要
  • 完了条件(Definition of Done)

ダッシュボードによる可視化

特に良いと感じたのは「要件 → 設計 → 実装」の流れが視覚的にも管理できる点です。
ダッシュボードで進捗を眺めながらAIとやりとりできるのは、まさに"仕様駆動"という感じでした。
プロジェクトの全体像が一目で把握でき、どの段階で問題が発生しているか、どこがボトルネックになっているかも即座に確認できます。

ダッシュボードでは以下の情報が表示されます:

  • プロジェクトの進捗率
  • 各フェーズの承認状態
  • タスクの完了状況
  • 生成されたドキュメントへのリンク
  • AIとの対話履歴

spec-workflow-mcpの課題

一方で、Cursorとブラウザを行き来する必要があるのは面倒で、文書量が増えてくると管理が大変になりそうです。
また、MCPサーバーのセットアップが必要なため、初期設定に多少の技術的知識が求められる点も、初心者にはハードルが高いかもしれません。

しかし、これらの課題を差し引いても、spec-workflow-mcpの提供する「確実性」と「透明性」は、特にミッションクリティカルなシステムの開発において大きな価値があると感じました。

4. cc-sdd - 日本発のオープンソースSDDツール

国産ツールならではの強み

cc-sddは、日本人エンジニアが開発したオープンソースの「仕様駆動開発(Spec-Driven Development)」ツールです。
AmazonのKiroに近い思想を持ち、「要件 → 設計 → タスク → 実装」という流れをIDE上で、AIと一緒に進められるようになっています。

日本の開発現場の実情を踏まえた設計になっているのが特徴です。
日本語での仕様記述が自然にできることはもちろん、日本企業でよく使われる開発プロセスや文書フォーマットにも対応しています。

簡単な導入と使いやすいインターフェース

導入は簡単で、プロジェクトにスラッシュコマンド群を追加すると /kiro:spec-init などを実行できるようになります。
これにより最初に要件定義ファイルが生成され、承認すると設計に進み、さらに承認するとタスク分解が行われて実装へ進むというワークフローになります。 cc-sddの技術的な優れた点は、既存の開発環境にスムーズに統合できることです。
以下のような環境で動作確認されています:

  • Claude Code
  • Cursor
  • Gemini CLI
  • VS Code(拡張機能経由)
  • JetBrains系IDE(プラグイン経由)

Project Memoryによる文脈の保持

興味深い機能として「Project Memory(ステアリング)」と呼ばれる仕組みがあり、プロジェクト固有の文脈やコーディングパターン、スタイルをAIに覚えさせることができます。
これによって繰り返し仕様を伝え直さなくても一貫性のあるコードを得られる点は、KiroのAgent Steeringに相当する機能です。

Project Memoryには以下のような情報を保存できます:

  • プロジェクトの背景と目的
  • チームのコーディング規約
  • 使用するライブラリとそのバージョン
  • ドメイン固有の用語集
  • 過去の設計決定とその理由
  • よく使うコードパターンやテンプレート

多言語対応と柔軟な設定

さらに、日本語を含む多言語に対応していることや、OSを自動判別してくれること、Kiro IDEとの互換性があることなど、実際の現場で使いやすい工夫が随所に盛り込まれています。

特に注目すべき機能は以下の通りです:

1.自動翻訳機能
英語で書かれた仕様を日本語に、日本語で書かれた仕様を英語に自動翻訳する機能があり、国際的なチーム開発にも対応できます。

2.テンプレート機能
よく使う仕様パターンをテンプレート化でき、似たようなプロジェクトを素早く立ち上げることができます。

3.バージョン管理との統合
Gitと深く統合されており、仕様の変更履歴を自動的にコミットメッセージに反映させることができます。

cc-sddの実践的な活用

個人の小さな開発からチームでの利用まで幅広く対応でき、仕様を中心に据えた開発スタイルを自分の手元の環境でも再現できるのが魅力です。
実際に使ってみると、以下のような場面で特に効果を発揮しました:

  1. レガシーコードのリファクタリング
    既存のコードから仕様を逆生成し、改善点を洗い出す

  2. 新規機能の追加
    既存の仕様に新しい要件を追加し、影響範囲を自動分析

  3. ドキュメントの自動生成
    仕様からAPIドキュメントやユーザーマニュアルを生成

cc-sddは、Kiroのような仕様駆動開発の体験をオープンソースで再現しつつ、日本語環境にも対応した「国産のSpec-Driven Development実装」だと言えます。

各ツールの比較と使い分け

機能比較表

機能 Kiro Spec Kit spec-workflow-mcp cc-sdd
日本語対応
承認フロー
プロジェクトガバナンス
IDE統合 ○(専用IDE)
オープンソース ×
エンタープライズ対応
学習コスト
カスタマイズ性

各ツールの適用シーン

使用体験を踏まえて、各ツールが適している場面をまとめると以下のようになります。

適用シーン比較表

適用シーン Kiro Spec Kit spec-workflow-mcp cc-sdd
大規模エンタープライズ開発
小規模チーム・スタートアップ
AWS環境での開発
厳格な品質管理
承認プロセス重視
素早いプロトタイピング
日本語での開発
GitHub中心のフロー
既存環境との統合
オープンソース重視 ×
カスタマイズ性
複数ステークホルダー

まとめ - SDDがもたらす開発の未来

全体を通して、SDDは仕様を中心に据えることで設計から実装、テスト、ドキュメントまでを一体的に進められることがわかりました。 今回紹介したツールはそれぞれに違った強みがあり、Kiroの自律性と堅牢性、Spec Kitのシンプルさと直感性、spec-workflow-mcpの承認フローによる品質保証、そしてcc-sddの日本語対応と柔軟性が特に印象に残りました。

実際に試してみると、仕様から逆算する開発には以下のような明確な価値があることがわかりました:

  1. コミュニケーションコストの削減 仕様が明文化され、全員が同じドキュメントを参照することで、認識の齟齬が大幅に減少します。 特に、AIとの対話を通じて仕様を洗練させていく過程で、曖昧さが自然に排除されていきます。

  2. 品質の早期確保 要件定義の段階から品質を意識することで、後工程での手戻りが減少します。 設計段階でのレビューも仕様に基づいて行われるため、より建設的な議論が可能になります。

  3. ドキュメントの自動生成と保守 仕様からドキュメントが自動生成されるため、「コードとドキュメントの乖離」という古典的な問題が解決されます。 また、仕様を更新すれば自動的にドキュメントも更新される仕組みは、長期的な保守性を大きく向上させます。

  4. AIとの効果的な協業 SDDツールを使うことで、AIの能力を最大限に活用できます。 仕様という明確な指針があることで、AIが生成するコードの品質と一貫性が保たれ、人間とAIの役割分担も明確になります。

一方で、SDDは開発の未来を変える可能性を秘めていますが、いくつかの課題も見えてきました:

ツールの成熟度 まだ多くのツールが開発初期段階にあり、安定性や機能の充実度には改善の余地があります。 特に、既存の開発プロセスとの統合や、レガシーシステムへの適用には工夫が必要です。

組織文化の変革 SDDを効果的に活用するには、「まず仕様を固める」という文化の醸成が必要です。 アジャイル開発に慣れたチームにとっては、この転換は容易ではないかもしれません。

AIへの過度な依存 AIが仕様から自動的にコードを生成してくれる便利さの反面、開発者の実装スキルが衰退する懸念もあります。 バランスの取れた活用方法を模索する必要があります。

結論として、仕様駆動開発は単なる新しい開発手法ではなく、ソフトウェア開発の本質的な課題に対する一つの解答だと感じました。 「何を作るか」を明確にしてから「どう作るか」を考えるという、一見当たり前のプロセスを、最新のAI技術と組み合わせることで実現可能にしています。

今回紹介した4つのツールは、それぞれ異なるアプローチでSDDを実現していますが、共通しているのは「仕様の重要性」への認識です。


最後にAlgomaticは一緒に働くメンバーを募集しています! 以下よりカジュアル面談お待ちしています!

jobs.algomatic.jp


実装の中で育てるClaude Code SDK理解:PoC自動化から得た学び

1. はじめに

こんにちは、Algomatic AXの岩城祐作(@yukl_dev)です。
私は5月にAlgomaticに入社し、AIエンジニアとして働いています。
入社エントリに、転職の背景の1つとして以下を書きました。

PoCループの虚しさと危機感 一方で、技術検証やデモ作成にとどまるPoC(Proof of Concept)も少なくありませんでした。 LLMOps導入など、生成AIの現場でよく用いられる実践的な経験を積み重ねる機会が少なく、AI領域に関わっているにも関わらずエンジニアとして活かせていない現状に、危機感が募りました。

果たして自分は本当に価値を提供できているのか?そもそも今の開発は本当に求められていることか?という不安が大きくなっていました。

企業支援のみを目的としたエンジニアでいることの危機感と無力感が、日に日に大きくなりました。

良ければ入社エントリもご覧ください。 note.com

「技術検証やデモ作成にとどまるPoC(Proof of Concept)」が意味のないものとは思いません。
ただ、エンジニアと顧客の双方がより価値ある時間を過ごせるように、以下を目指してPoC自動化プロダクトの開発に取り組み始めました。

  • エンジニアが専門的な課題に価値投下できる状態を作る
  • 属人化する必要のないPoCに必要な知見を集約し、同種PoCの初速を最大化する
  • 各エンジニアや組織にとってより価値のある知見の蓄積につなげる

Claude Code SDK」を使って実装を進めており、今回はその実装過程で得られたClaude Code SDKに関する知見を共有します。

2. Claude Code SDKの概要

Claude Code SDKとは何か

開発者がターミナルで対話的にClaudeとやり取りするClaude CodeのCLI利用は、皆さんイメージできると思います。

Claude Code SDKは、CLIと同様のclaude実行ファイルをアプリケーション側から操るためのライブラリです。

イベントやストリームを受け取りながら、計画から適用、ツール実行まで非対話(ヘッドレス)でプログラム制御できる仕組みを提供しており、アプリケーションとして作り込みやすいです。

docs.anthropic.com

なお、claude -pを使えば、CLIでも非対話(ヘッドレス)で実行は可能です。本プロダクトでは、アプリケーション側でのオーケストレーションによる拡張性と制御性を優先し、Claude Code SDKを採用しています。

TypeScript版とPython版の特徴

Claude Code SDKは現在、TypeScriptとPythonの2つの言語で提供されています。

TypeScript SDK

  • npmパッケージ@anthropic-ai/claude-codeでCLIと一緒にインストール
  • CLIと同様のclaude実行ファイルを直接扱うので、無駄な処理なくよりネイティブな操作感

Python SDK

  • pip install claude-code-sdkに加え、Node.jsと@anthropic-ai/claude-codeの導入が必須
  • 内部でCLIを起動し、JSONストリームをパースする仕組み
  • CLI未導入時にはCLINotFoundErrorなど専用例外でエラーハンドリング

3. Claude Code SDKを使って得られたこと

Permission Modesによる安全な実行計画

Claude Codeでは、以下の4つのPermission Modesが利用可能で、それぞれ安全性や利用シーンに応じて選択できます。

Mode 説明 使用シーン
default 標準動作 - 各ツールの初回使用時に権限確認 通常の開発作業、手動確認を重視したい場合
acceptEdits セッション中のファイル編集権限を自動承認 開発効率を重視、ファイル変更が頻繁な作業
plan 分析のみ可能、ファイル変更・コマンド実行は禁止 コードレビュー、設計検討、安全な事前確認
bypassPermissions 全ての権限プロンプトをスキップ(安全な環境必須) CI/CD、完全自動化された環境での実行

Identity and Access Management - Anthropic

私のPoC自動化プロダクトでは、3つのエンドポイントのモードを個別設定して実装することで 「計画 → 承認 → 継続改修」のフローを自動化しつつ、安全性と柔軟性を両立 しています。

  • POST /api/poc/build
    • モード: plan
    • 計画のみを生成し、ファイル編集やコマンド実行は行わない。
  • POST /api/poc/approve
    • モード: default
    • 承認後、同じセッションで実行に移行。ツール使用時には初回のみ確認が入り、以降はセッション内で承認済みとして進行。
  • POST /api/poc/extend
    • モード: default
    • 追加改修も同一セッションのまま行われ、同じ権限制御が適用される。(まだ不安定…)

さらに、defaultモードで権限確認が発生した場合でも、同じ approve エンドポイントを介して応答することで、セッションを途切れさせずに継続できるように設計しています。

コマンドレベルで制御を実現

allowedToolsdisallowedToolsを使って、具体的なコマンドレベルの制御もしています。

  • allowedTools: 明示的に「利用を許可する操作」を列挙。指定した範囲内の操作は確認なしで実行される。
  • disallowedTools: 明示的に「禁止する操作」を列挙。指定にマッチする操作はセッション内でブロックされる。

現時点のPoC自動化プロダクト内のコマンドリストは、最低限のものを指定していますが、部署やチームと調整してアップデートする予定です。

// 設定例
const options = {
  allowedTools: [
    "Read",
    "Bash(npm install)",
    "Bash(npm run test:*)",  // test系コマンドを許可
    "Edit(src/**)"           // srcディレクトリ内の編集を許可
  ],
  disallowedTools: [
    "Bash(rm *)",
    "Bash(sudo *)",          // 危険なコマンドを拒否
    "Edit(config/production.json)"  // 本番設定の変更を禁止
  ]
}

Hooksによる確実な実行

Claude Code hooksは、各ツールの実行前後に外部コマンドを自動実行する機能です。

Hooksの基本概念

Hooksは、複数のタイミングで処理を差し込むことができます。
代表的なイベントは次の通りです。

  • PreToolUse: ツール実行前に呼び出される
  • PostToolUse: ツール実行後に呼び出される
  • SessionStart: セッション開始時に呼び出される
  • Notification: 権限待ちなどの通知タイミングで呼び出される
  • UserPromptSubmit: ユーザーのプロンプト送信直後に呼び出される

そのほかに PreCompact / Stop / SubagentStop などのイベントがあります。

Hooks reference - Anthropic

これらを活用することで、より柔軟な制御と確実なワークフローの実行が可能になります。

その他Hooksの詳細と事例については、弊社の柗村@yu_mattznの記事もご覧ください。

tech.algomatic.jp

ドキュメント自動生成の実装

私のPoC自動化プロダクトでは、以下が実現したいことでした。

  • 作り直し前提の開発サイクル:次フェーズ(本番開発)への移行を容易にし、作り直し前提とする開発サイクルのハードルを下げる
  • 速度と検証の両立:対象の検証速度を早めつつ、検証結果(特に実現可能性)を明確にする。この説明責任を大切にする

そのため、PostToolUseを使って、基本機能とその実現方法などの以下ドキュメントを残す工程を自動化しました。

  • README.md: 生成したアプリケーションの全体像と使い方
  • POC_REQUIREMENTS.md: PoCの検証内容や要件
  • FEATURES_IMPLEMENTATION.md: 実装機能とその実現方法
  • ARCHITECTURE.md: 全体構成と設計意図

4. まとめ

今回は、PoCの自動化を目指す中でClaude Code SDKを活用した実装知見を共有しました。
本記事はClaude Code SDKの紹介がメインでしたが、PoC自動化プロダクトについてはまた別の機会に共有したいです。
引き続き形にしていく取り組みを進めてまいりますので、ご意見やフィードバックをいただければ幸いです。


最後にAlgomaticは一緒に働くメンバーを募集しています! 以下よりお気軽にカジュアル面談をお申し込みいただけると幸いです!

jobs.algomatic.jp


Claude Code hooksで始めるPromptOps:チームで意図を残す仕組み作り

こんにちは。Algomatic AI Transformation(AX) の柗村@yu_mattznです。

私は7月にAIプロダクトエンジニアとして入社し、今はネオデザインAIの開発責任者をしています。プロダクト出身でAIについての深い知見はないため、日々AIエンジニアの方々の投稿からキャッチアップできて最高な環境です。

今回は、Claude Codeをチームで使う際、プロンプトを共有するのが今後大事になってくるのではないか?と考えたきっかけとその取り組みを紹介します。

Claude Codeを導入してみて

Claude Codeが出た時、部署では一瞬で使用を許可していただきました。(爆速。感謝)

使ってみて、フロントもバックエンドも一通して開発させることができ、実装スピードは跳ね上がりましたが、バックエンドは自身が使用してきた言語ではなかったのもあり、コードレビューがボトルネックになりました。

そこで、いかに並行開発しスピードを出すか、より、どうやってレビューをしやすくするか、を考えるようになりました。 (もちろんAIにレビューさせる前提で、どこまでレビューするかはプロダクトや組織によるとは思いますが、完全Vibe codingは立場上できませんでした。)

コーディングの意図が分からないとレビューがしづらい

Claude Codeに実装させてpull requestを出す -> GitHubのpull request画面でレビューをする。他のメンバーのコードも同時にレビューしていて、自分の体感ではAIで書かせたコードのレビュー時間の方が短くできました。

他のメンバーのコードレビューでもAIが書いたコードレビューでも、pull requestは基本的には「何をしたか(What)」が記述されます。しかし、AIに私がコードを書かせた場合、レビューする側(つまり私)は、その背景にある「なぜこれが必要だったのか(Why)」を理解しながらプロンプトに打ち込んでいます。自分の意図がプロンプトに込められており、目で処理を追いながら、動作の度に止めたり再開したりの試行錯誤をしている時もあるので、大体のコードは頭に入っています。

人のコードに対してはGitHub上でのコミュニケーションで捕捉していると思います。

この問題は、Vibe codingで生まれたプロトタイプをプロダクトに昇格させるような、引き継ぎの場面でより顕著になりました。

  • 技術選定の背景がわからない(ex. なぜプロダクト1はNext.jsで、プロダクト2はReact+Viteなのか?)
  • ドキュメント化されていない「お作法」や「秘伝のタレ」のようなコードが存在する
  • 変更を加えたくても、意図が不明なため影響範囲が読めず、修正が怖い

コードレビューや運用保守において、表面的な「What:どういう変更か」だけでなく、そのコードが生まれた背景にある「Why:なぜこのコードが生まれたか」、つまり開発者が込めた意図を知りたい瞬間って結構あると思います。

これだけだと、CLAUDE.mdにコーディングの意図を含めてコメントやGitのコミットメッセージに書くように指示をして終わりですがもう一つ別の観点で。

AIコーディングエージェントの使用Tipsの共有・伝承

ペアプロ・モブプロっていいですよね。VSCodeの便利な使い方や、Excelのショートカットなどでも、普段意識することないレベルに使い込まれた技能を知ることができ、地味なんだけど生産性がとても上がったことを覚えています。

Claude Codeのように丸っと頼めるコーディングエージェントを使用していて、設定などは共有できるとしても、どういうプロンプトを打って開発させているのか、をチームで共有し、学ぶことに価値があるのではないか?と思うようになりました。

使用したプロンプトを残して共有する

上二つの観点から、私は「AIに与えたプロンプトを残し、共有することが今後大事になってくるのではないか」と考えました。

最初はCLAUDE.mdに書いたプロンプトをファイルに記載するように頼んでいたのですが、たまに無視するし、トークンを節約してるのか英語で書いたりと散々でした。

Claude Code hooks

そんな時に出たのがClaude Code hooks。特定のイベント後に確定でアクションを起こせます。最初はClaude Codeが終了した際に、発行されるStopイベントを利用していましたが、ユーザーが自ら止めた時に動かなかったり、プロンプト自体を取ることができなかったのでtranscript_pathに貯まるログファイルから抽出する手間があったりしたんですが、

最近しれっと追加されたUserPromptSubmitイベント。 このイベントは、ユーザーがプロンプトを叩くたびに発行され、InputのkeyにPromptが存在していて取り回しもしやすいです。

今回はUserPromptSubmitを使って、pull requestの詳細に使用したプロンプトが全て記載されるようにした仕組みを紹介します。 (ファイルとしてそのまま残すのも考えましたが、AIが開発時にノイズになったり、ディレクトリに残ってるのも微妙か?と考え、pull requestに全て乗るように作りました)

Step 1: Claude Code hooksでプロンプトを保存する

以下のスクリプトを.claude/scripts/save_prompt.shとして配置します。このスクリプトは、プロンプトが実行されるたびに、その内容をプロジェクトルートの.claude/prompts.logファイルに追記します。

#!/bin/bash
set -euo pipefail

# プロジェクトルートを取得(Claude Codeがcdで動き回るため固定)
repo_root=$(git rev-parse --show-toplevel)

# ログファイルのパス設定(プロジェクトの.claudeディレクトリ内)
LOG_DIR="$repo_root/.claude"
LOG_FILE="$LOG_DIR/prompts.log"

# 標準入力からJSONを読み込む
input=$(cat)

# jqを使ってプロンプトとセッションIDを抽出
if command -v jq >/dev/null 2>&1; then
  prompt=$(echo "$input" | jq -r '.prompt // "No prompt"')
  session_id=$(echo "$input" | jq -r '.session_id // "unknown"')
  cwd=$(echo "$input" | jq -r '.cwd // "unknown"')
else
  echo "❌ jqがインストールされていません。jqをインストールしてください。" >&2
  exit 1
fi

# タイムスタンプ
timestamp=$(date '+%Y-%m-%d %H:%M:%S')

# ログに追記
{
  echo "[$timestamp]"
  echo "Session ID: $session_id"
  echo "Working Directory: $cwd"
  echo "Prompt: $prompt"
  echo "=========================================='"
  echo ""
} >> "$LOG_FILE"

echo "✅ プロンプトをログに記録しました: $LOG_FILE" >&2
exit 0

これを.claude/settings.jsonに記載します。

{
    "$schema": "https://json.schemastore.org/claude-code-settings.json",
    "hooks": [
        {
            "event": "UserPromptSubmit",
            "script": ".claude/save_prompt.sh"
        }
    ]
}

.claude/settings.jsonを共有していてhooksを書いてる場合、チームメンバーは許可する・しないに関わらず、スクリプトが実施されてしまうので、お気をつけて・・・! (OSSをインストールしてClaude Codeを使用する際にもお気をつけて)

Claude Codeを最初起動する時の注意書き

Step 2: githooksでプロンプトをコミットメッセージに含める

ログファイルにプロンプトを記録するだけでは、どのプロンプトがどの変更に対応するのかわかりません。そこで、git commitを実行する際に、記録されたプロンプトを自動でコミットメッセージに含めるようにします。

Gitのprepare-commit-msgフックを利用します。以下の内容を.git/hooks/prepare-commit-msgとして保存し、実行権限を付与してください。

#!/bin/bash

# prepare-commit-msg hook
# コミットメッセージファイル、コミットタイプ、SHA1を受け取る
COMMIT_MSG_FILE=$1
COMMIT_SOURCE=$2
SHA1=$3

# プロンプトログファイル
PROMPTS_LOG=".claude/prompts.log"

# prompts.logが存在する場合のみ処理を実行
if [ -f "$PROMPTS_LOG" ]; then
    # 既存のコミットメッセージを一時保存
    TEMP_MSG=$(cat "$COMMIT_MSG_FILE")
    
    # prompts.logから全プロンプトを抽出(重複を除去)
    PROMPTS=$(grep "^Prompt: " "$PROMPTS_LOG" 2>/dev/null | sed 's/^Prompt: //' | sort -u)
    
    # プロンプトが見つかった場合のみ追加
    if [ -n "$PROMPTS" ]; then
        # プロンプトを整形
        ADDITIONAL_MSG="## Claude Code プロンプト履歴"$'\n'
        while IFS= read -r prompt; do
            ADDITIONAL_MSG+="- $prompt"$'\n'
        done <<< "$PROMPTS"
        
        # 新しいメッセージを作成(既存のメッセージ + プロンプト履歴)
        cat > "$COMMIT_MSG_FILE" << EOF
$TEMP_MSG

$ADDITIONAL_MSG
EOF
    fi
    
    # prompts.logを削除
    rm "$PROMPTS_LOG"
    echo "✓ $PROMPTS_LOG を削除しました"
fi

exit 0

Step 3: GitHub Actionsでpull requestに集約する

pull requestが作成・更新されたタイミングで、そこに含まれる全てのコミットからプロンプト履歴を抽出し、PRのdescriptionに自動で追記するGitHub Actionsのワークフローを作成します。

.github/workflows/update_pr.ymlとして以下のファイルを作成します。

name: Update PR with User Instructions

on:
  pull_request:
    types: [opened, synchronize]
  workflow_dispatch:

permissions:
  pull-requests: write
  contents: read

jobs:
  update-pr-description:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Update PR description with user instructions
        uses: actions/github-script@v7
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const pr = context.payload.pull_request;
            if (!pr) {
              console.log('No PR found in context');
              return;
            }

            const { data: commits } = await github.rest.pulls.listCommits({
              owner: context.repo.owner,
              repo: context.repo.repo,
              pull_number: pr.number
            });

            const userInstructions = new Map();
            let totalCommits = 0;
            let commitsWithInstructions = 0;

            for (const commit of commits) {
              totalCommits++;
              
              const lines = commit.commit.message.split('\n');
              let inPromptsSection = false;
              const instructionLines = [];

              for (const line of lines) {
                if (line.includes('## Claude Code プロンプト履歴')) {
                  inPromptsSection = true;
                  continue;
                }
                if (inPromptsSection && line.startsWith('##')) {
                  inPromptsSection = false;
                }
                if (inPromptsSection && line.trim().startsWith('- ')) {
                  const instruction = line.trim().replace(/^-\s*/, '').trim();
                  if (instruction) {
                    instructionLines.push(instruction);
                  }
                }
              }

              if (instructionLines.length > 0) {
                commitsWithInstructions++;
                for (const instruction of instructionLines) {
                  userInstructions.set(instruction, (userInstructions.get(instruction) || 0) + 1);
                }
              }
            }

            let commitSection = '## 📝 ユーザー指示履歴\n\n';
            if (userInstructions.size === 0) {
              commitSection += `このPRには${totalCommits}件のコミットがありますが、明確なユーザー指示は含まれていません。\n`;
            } else {
              commitSection += `総コミット数: ${totalCommits}件(うち${commitsWithInstructions}件にユーザー指示あり)\n\n`;
              commitSection += '### ユーザー指示一覧:\n\n';
              const sortedInstructions = Array.from(userInstructions.entries()).sort((a, b) => b[1] - a[1]);
              for (const [instruction, count] of sortedInstructions) {
                commitSection += `- ${instruction}${count > 1 ? ` (${count}回)` : ''}\n`;
              }
            }

            const currentBody = pr.body || '';
            const commitSectionRegex = /## 📝 (?:コミット履歴|ユーザー指示履歴)[\s\S]*?(?=\n## |$)/g;
            let newBody = currentBody.replace(commitSectionRegex, commitSection.trim());

            if (newBody === currentBody) {
              newBody = currentBody + '\n\n' + commitSection;
            }

            await github.rest.pulls.update({
              owner: context.repo.owner,
              repo: context.repo.repo,
              pull_number: pr.number,
              body: newBody
            });

結果

この仕組みを導入することで、pull requestには以下のような「ユーザー指示履歴」が自動で追加されるようになります。

実際の画面

レビュアーは、コードの変更がどのような意図で行われたのかを把握できるし、チームメンバーがどのようにClaude Codeに指示を出しているかを理解し、どう使っていくのかの共有もできるようになりました。

まとめ

今回はAIが開発するのが当たり前になる世界観では、そのコードを生み出した「意図(プロンプト)」を管理し、チームで共有するかが大事になってくるのではないか、という仮説のもと、取り組みを紹介しました。


最後にAlgomaticは一緒に働くメンバーを募集しています! 私のようなプロダクトエンジニアも募集しているので、以下よりお気軽にカジュアル面談をお申し込みいただけると幸いです!

jobs.algomatic.jp

オープンウェイトモデルで広がる生成AI活用: LLM API活用の課題と自社運用

はじめに

こんにちは。Algomatic AI Transformation(AX) のsergicalsix(@sergicalsix)です。

近年、大規模言語モデル(LLM)の登場により、AIがビジネスの現場で急速に浸透しています。ChatGPTやClaudeなどのAPIを活用し、業務効率化や新サービス開発に取り組む企業も増えてきました。

しかし、実際にLLMをAPIで活用しようとすると、コストや安全性などの課題にぶつかることがあります。

その課題の解決策として、本記事ではオープンウェイトモデル(モデルの重みパラメータが公開されており、自由にダウンロード・利用できるLLM)の活用という観点で事例や先行研究をご紹介していきます。

LLMのAPI活用の課題

LLMのAPI活用における課題として、今回取り上げる課題は以下3つです。*1

コスト面の課題

LLMを本格的に業務へ導入すると、API利用料は短期間で高額になり得ます。 例えば、社内のナレッジベースから検索・要約を行うシステムや、大量の顧客対応を自動化するチャットボットでは、「1リクエストあたり数円」でも、数十万〜数百万リクエストが積み重なれば月間で数百万円規模のコストになることも珍しくありません。 さらに、モデルの大型化やコンテキスト長の増加に伴ってコストが増加するという構造的な課題もあります。 *2

速度面の課題

リアルタイム性が求められる業務では、APIの応答速度が致命的な制約になります。 たとえば、顧客とのチャットサポートや現場作業員への指示出しなどでは、わずか数秒の遅延でもUXの悪化やオペレーション効率の低下につながります。 特に大規模モデルでは、推論計算自体の遅延に加え、API経由のネットワーク遅延、さらにプロンプトやコンテキストの長文化によるトークン生成速度の低下が複合的に影響します。*3

安全面の課題

業務でAPIを活用する場合、データが外部に送信されることによる情報漏洩リスクや、生成結果の正確性・安全性の担保といった問題も避けられません。 特に法務や金融、医療分野では、誤った生成結果が即座に業務リスクにつながるため、単に「高性能モデルを使う」だけでは不十分です。 これらはモデルそのものの性能というより、API活用時の運用設計などの問題ですが、生成AI導入には避けて通れません。


これらの課題は、多くの企業がLLM APIを本格活用する際の障壁となっています。

解決策としてのオープンウェイトモデルの自社活用

前章で述べた3つの課題に対して、有効な解決策として注目されているのが「オープンウェイトモデルを自社の閉域網内で運用する」というアプローチです。

これにより、以下のメリットが期待できます。

  • コスト:ランニングコストの削減

  • 速度:通信遅延削減による低レイテンシー実現

  • 安全性:データが社外に出ないため、セキュリティリスクが軽減

ただオープンウェイトモデルの活用には欠点があり、その一つが性能面です。一般的にオープンウェイトなモデルは、現在最も性能が高いと言われているGPT-5やClaude Opus 4、Gemini 2.5 Proなどのクローズドなモデルと比べて性能が低いです。その理由の一つには、モデルサイズが小さいことが挙げられます。

ただタスク特化させた場合は、必ずしもモデルサイズが性能に比例するわけではありません。例えばコード生成系のタスクにおいてCodeLlama 7BがLlama 2 70Bよりも精度が高いことが報告されています(Subramanian et al., 2025)。

このように、個別タスクに特化させることにより「小さくても強い」モデルの構築が可能であることが明らかになっています。

さらにこのような背景の中、約1週間前に発表された「gpt-oss」は、o3-miniなどの既存モデルに匹敵する性能であることが報告されています(Open AI, 2025)。 gpt-ossについては特に注目度が高く、弊社(株式会社Algomatic)や株式会社リコー様が実用化に向けた取り組みを発表しています。

prtimes.jp

jp.ricoh.com

次章では、オープンウェイトモデルの具体的な導入・活用手法について、最新の研究成果をもとに解説します。

オープンウェイトモデルの活用

本章では、オープンウェイトモデルを実践的に活用するための2つのアプローチを紹介します。

1. 既存システムからの移行

2. 複数モデルを組み合わせたハイブリッド運用

以下で紹介する手法は、元々Small Language Model (SLM) のarXivで提案されたものですが、オープンウェイトモデルに適用可能なフレームワークのため紹介していきます。

以下では、オープンウェイトモデルを自社環境にデプロイして運用する場合を「自社運用モデル」と呼びます。

既存システムからの移行(Belcak et al., 2025)

Belcak et al., 2025は、既存システムから自社運用モデルへの移行プロセスを6つのステップで整理しています。またこれらは必ずしもAPIを利用しているシステムからの移行のみならず、人間が実施している業務でも同様の移行プロセスを実施することが可能です。

Step1. データ収集

まずは既存のモデルやエージェントが処理したすべての入出力ログを網羅的に集めます。 対象はテキストプロンプトやモデルの応答だけでなく、外部ツールやAPIの呼び出し履歴、検索クエリ、ユーザーのクリックや選択などの行動データも含まれます。 特に後続の分析や改善では、モデルの出力だけではなく「なぜその結果になったのか」を追えるコンテキスト情報が重要です。そのため、リクエストのタイムスタンプ、ユーザー属性(匿名化済み)、使用モデルやバージョンなどのメタデータも併せて収集します。

Step2. データ前処理

収集したデータは、そのままでは学習に使えません。品質の低いデータやリスクのある情報が混ざっているため、次のような処理を行います。

  • 個人情報や機密情報の削除/マスク

例:氏名、住所、メールアドレス、顧客IDなどを正規表現やNER(固有表現抽出)で検出し匿名化。

  • ノイズの除去

無意味な会話や重複データ、明らかな誤回答などを除去し、学習効率を高めます。

  • データの正規化

言い回しや表記揺れ(例:「メール」「Eメール」)を統一し、モデルが学習しやすい形に整えます。

  • バリエーション生成(パラフレーズ作成)

同じ意味を異なる表現で追加することで、モデルの汎化性能を向上させます。

こうした処理により、安全かつ多様性のある高品質データセットが得られます。

Step3. タスクのクラスタリング

ログを分析し、類似タスクをグルーピングすることでデータを分類します。これにより、各領域に特化したカスタムモデルやプロンプトチューニングが可能になります。

補足ですが、Step2. データの前処理とStep3. タスクのクラスタリングについては、以下に詳しく記述されています。

arxiv.org

arxiv.org

Step4. モデル選定

クラスタリングされたタスクごとに、性能・推論速度・コンテキストウィンドウ・運用要件などを総合的に評価し、最適なモデルを選びます。 ここでは単一の指標を見るだけではなく、各タスクに最も適した特性を持つモデルを選び、無駄な計算資源を削減しながらも必要な精度を確保することが重要です。

Step5. チューニング

プロンプトチューニングや選定したモデルに対して、LoRAやQLoRAなどでファインチューニングを行います。必要に応じて、蒸留も活用し、性能を補強します。 こうした軽量かつ効率的な学習手法を組み合わせることで、限られたリソースでも実運用に耐える精度と応答速度を実現できます。

Step6. 継続的な改善

運用後についてもStep2〜Step5の工程を繰り返し、精度や速度向上などを実施します。 新しい利用パターンやデータが蓄積されるたびにモデルを更新し、変化する業務ニーズやユーザー期待に対応できる状態を保つことが大切です。


しかし、すべてのタスクを一度に移行するのは現実的ではない場合もあります。 次節では、段階的な移行を可能にするハイブリッドなアプローチを紹介します。

複数モデルを組み合わせたハイブリッド運用(Chen et al., 2025)

完全な自社運用モデル移行が困難な場合でも、以下の4つのパターンでクローズドモデル(API)とオープンウェイトモデルを効果的に組み合わせることで、コスト削減とセキュリティ向上を実現できます。*4

1. Pipeline(パイプライン)

処理を複数のステップに分解し、自社運用モデルで前処理や定型作業を実行後、その結果をAPIに渡して後続の処理を実行します。

例えばCoGenesis(Zhang et al., 2024)では、端末上のSLMが個人のコンテキストを読み取って整形し、クラウド上のLLMがタスクを実行するといったワークフローが採用されています。

CoGenesisの概念図(Zhang et al., 2024)

2. Routing(ルーティング)

入力内容の複雑度や機密性に応じて、自社運用モデルとAPIを動的に使い分けます。簡単なタスクは自社運用モデルで素早く回答し、難しいタスクはAPIを通じて実施します。

例えばCITER(Zheng et al., 2025)では、出力の生成過程をトークン単位で制御し、定型的な部分や平易な部分はSLMが生成し、重要度が高く正確さが必要な部分はLLMが担当します。このルーティングは強化学習で最適化され、品質とコストのバランスを取っています。

CITERの概念図(Zheng et al., 2025)

3. Auxiliary(補助/強化)

APIをメインとしつつ、自社運用モデルが前処理や情報抽出で支援します。例えば自社運用モデルが社内文書から関連情報を検索・構造化し、その結果をコンテキストとしてクローズドモデルに提供するなどです。

例えばCollab-RAG(Xu et al., 2025)では、SLMが複雑な質問を複数のサブクエリに分解することで検索精度を向上させ、LLMが最終的な回答を作成します。

Collab-RAGの概念図(Xu et al., 2025)

4. Knowledge Distillation(知識蒸留)

クローズドモデルの出力を教師データとして、自社運用モデルを改善します。

例えば全体の出力のN(0 < N < 100)%をAPIで処理し、データを収集することで自社運用モデルを継続的に訓練するといった活用方法が考えられます。

余談ですが、知識蒸留については以下のサーベイ論文に参考になります。

arxiv.org

複数モデルを組み合わせたパターンの選択指針

所属されているチームの優先事項や目的に応じて、以下のアプローチを選択すると良いです。

  • コスト削減: Pipelineを採用し、前処理や簡単な処理を自社運用モデルで対応

  • セキュリティ最優先: Routingを採用し、機密データが関わる部分を自社運用モデルに分離

  • 精度向上: Auxiliaryを採用し、社内ナレッジや専門知識を自社運用モデルで補強

  • 段階的移行: Distillationを採用し、徐々に自社運用モデルを強化

まとめ

本記事では、LLM APIの活用で多くの企業が直面する「コスト」「速度」「安全性」の課題に対して、オープンウェイトモデルの活用は現実的な解決策の一つです。

定型的なタスクから自社運用モデル化を始め、徐々に適用範囲を広げていくといったアプローチやハイブリッドなモデル運用などが今後必要になってくるかもしれません、

今後もオープンウェイトモデルの動向を注視しながら、最適な活用方法を模索していきたいと思います。


最後にAlgomaticは一緒に働くメンバーを募集しています!

以下よりお気軽にカジュアル面談をお申し込みいただけると幸いです!

jobs.algomatic.jp

*1:今回取り上げなかった課題として、①オフライン環境またはネットワーク速度が低い環境で使えない②エネルギー制約がある場合に使えないといった課題があります。①は概ね速度面の課題や安全面の課題で吸収でき、②はまだ日本で課題として顕在化していないと判断しています。

*2:コスト面の課題に対する対処法として本記事では触れませんが、①定額課金制のサービスを使用する②性能が高く安価なモデル(例: Gemini 2.5 Flash)を使用するなどがあります。

*3:速度面の課題に対する対処法として本記事では触れませんが、CerebrasやGroqなどの高速なプロバイダーを使うなどがあります。

*4:Chen et al., 2025内では、紹介したパターン以外にIntegration/Fusionが紹介されています。しかしアーキテクチャレベルや重みレベルのモデル統合は本記事の対象外であるため、紹介していません。

LLMで"何でも"できる時代のAIエンジニア生存戦略 - LLMのグラウンディング能力について

結論

  • LLM/VLMで"何でも"できる時代に、LLMにはグラウンディングという苦手な事があります
  • LLM/VLMを、グラウンディングができるモデルとうまく組み合わせるといいかもしれません
  • この「グラウンディングをどうするか」が次世代のAIエンジニアに求められるスキルの一つかもしれません

結論は以上です。


こんにちは。 AlgomaticのAXカンパニーでは現在AIエージェントネイティブなデザインツールネオデザインAIを開発しています。

neodesign-ai.com

今回は、AIエンジニアとしてこのプロダクトのAI技術開発に携わる中で得られた知見について、皆さんにお伝えしたいと思います。


* この記事は現在進行形で発展している技術領域についての考察であり、また、筆者の個人的な見解や推測を含んでいます。AI技術の進歩は非常に速く、記事執筆時点での情報や分析が将来的に変わる可能性があります。また、技術的な内容については間違いや不正確な部分が含まれている場合もありますので、重要な判断を行う際は最新の情報や専門的な資料もあわせてご確認いただければと思います。


ネオデザインAIとは

ネオデザインAIの対象ドメインは、広告クリエイティブのデザインです。 クリエイティブとは、SNSの広告などで使われる画像のことです。

このようにイベントの広告や商品の宣伝で使われるものがあります。

クリエイティブを制作するときには様々なステップがあります。 例えば、クリエイティブを制作するための情報が載った企画書を理解し、テンプレートを選ぶ、細かくデザインを修正するなど、そのステップは多岐にわたります。

私たちが開発しているネオデザインAIでは以上のようなプロセスにおいて人の作業コストを減らすことを目標としています。 今まではデザイナーが担当していた箇所をプロダクトが代わりに行うことで、非デザイナーでもクリエイティブの作成を行うことができるようになることを目指しています。


レイアウト理解タスクとは

私たちが開発しているプロダクトにおいて重要なのは、AIがクリエイティブのレイアウトを深く理解する能力です。 私たちはレイアウトの理解タスクを以下の要素を検出することと定義します。

要素
画像 位置・大きさ
テキスト 位置・大きさ・フォント・ウェイト・カラー
図形 形状・位置・サイズ
コンポーネント 画像+商品名テキストなどのまとまり
変数判定 クリエイティブの要素の中でよく変更されるであろう要素

"深く"理解するとは?: 以下の図に示すように、レイアウトを理解するには位置や大きさといったピクセルレベルのものから、フォントやコンポーネントといった抽象度の高いものまで検出・理解する必要があります。

変数判定: レイアウト理解タスクにおける変数とは、あるクリエイティブのレイアウトを全く同じものを用いて、別のことを宣伝したい時に変更すべき箇所です。 例えば、この猫フェスのクリエイティブのテンプレートを用いて犬のフェスの宣伝を行いたい場合には、「猫の画像」と「ねこフェスというテキスト」を変更する必要があることが考えられます。

これらがなぜ私たちのプロダクトにおいて重要かというと、例えば「会社が持つ既存のルールを守った高品質テンプレート生成」や「デザイン品質保証」には 精密なレイアウト理解 が不可欠だからです。

しかし、以上のようにAIがデザインをうまく扱うにはいろいろな課題があると私たちは考えました。 その中でも今回は、

VLMのグラウンディング能力の欠如

について解説したいと思います。

従来手法の課題

レイアウト理解タスクにおいて既存のAIが直面する最大の困難は、単一の技術では解決できない複合的な能力が要求されることです。具体的には、①グラウンディング能力、②セマンティックな理解能力、そして③推論能力という、異なる性質を持つ高度な能力を同時に必要とします。

①グラウンディング能力 "グラウンディング能力"とは、"AIが言葉や概念を、具体的なものや実際の世界と結びつけて理解する能力"のことです。 LLMの"グラウンディング能力"として身近なものとしては、検索結果を利用して事実に基づく、という意味で聞いたことがあるかと思います。 この「グラウンディング」という単語は他の分野、例えば画像分野でも使われます。 画像分析におけるグラウンディング能力の一つは、AIが画像内で「どこに」オブジェクトが配置されているかを正確に特定する能力のことです。これは空間的な位置関係の理解に関わる基礎的な視覚認識能力です。

②セマンティックな理解能力 AI分野におけるセマンティックとは、単純な物体認識を超えた抽象度の高い意味性の理解を意味します。 例えば、クリエイティブの中に、「猫の画像」がある、などをいうことを意味します。 例えば、猫という認識をせずにオブジェクトの位置だけを検出する場合はそれはセマンティックなタスクとは言わないことが多いでしょう。

③推論能力 さらに、近年話題になっているReasoningという概念があります。LLMの場合だと、これは複雑な問題に対して理由をつけて(トークンを消費して)回答をする能力を一般的には指しています。例えば、「画像の中で喉が渇いた時に欲しい物はどこにある?」という指示に対して、水の入ったペットボトルを見つけるには、喉が渇いた時に欲しい物とは何かを推論する必要があります。 例えば、上記の例の画像の「ねこ」と「フェス」のテキストはグループになる、などというには、フォントが同じだから、とか、猫フェスで繋がるから、など推論能力が必要とされます。

このような技術が要求されるため、従来の手法ではレイアウト理解タスクにおいて十分な性能を発揮できませんでした。以下に具体的な事例を解説します。

LLM/VLM

私たちは開発当初、大規模言語モデル(LLM)と視覚言語モデル(VLM)を活用したレイアウト理解手法の開発に着手しました。最も直接的なアプローチとして、VLMにクリエイティブ画像を入力し、画像内の要素の位置情報を座標ベースで出力させる手法を試行しました。

しかし、この手法では期待された精度を得ることができませんでした。 VLMやLLMは言語や画像のコンテキストでの理解に最適化されているため、「ここに商品画像が配置されている」といった定性的な記述は可能である一方、座標値(x, y)やサイズ情報(h, w)を数値として定量的に正確に出力することに本質的な困難を抱えていることが予想されます。 この結果は、言語モデルの設計思想が連続的な数値処理よりも離散的なトークン処理に特化していることに起因すると考えられます。

GoogleはGeminiを用いてSpatial Understanding、つまり物体検出ができることを提案しています。 これはGeminiに画像を与えてBoundingBoxをJSON形式で出力させるというものです。 Bounding Boxとは物体検出において広く用いられる座標の羅列形式です。 例えば (x_min, y_min, x_max, y_max) という羅列です。これを用いると検出対象の物体を囲む四角形を描画することができます。 以下に示すように私たちはこれを試しましたまだ精度が不十分です。

Set-of-Mark Promptingではこれらの課題をスマート解決しています。

Set-of-Markではまず、画像に対してSAMなどのモデルを用いて"すべてに適当に"セグメントを行います。 その後、セグメント領域全てにIDを振り、そのIDを画像に直接描画します。 その数字が描画された画像をクローズドなVLM(論文ではGPT4V)に直接入力することで、出力のテキストの中でIDを用いて回答をセグメントマスクでグラウンディングできるようにします。 こうすることで、VLM(GPT4V)にセグメントの情報が入力・出力できない問題を解決しています。

しかし、以下の問題が論文で指摘されています。

  • 小さいセグメントの上に大きなセグメントが被る
  • 番号が別のセグメントの上に重なる
  • セグメントの数が多くなったり、セグメント自体が小さくなるとIDの数が膨大になり、画像に正確にIDを記載させるのが難しくなる

特にクリエイティブは、要素の数が多いのでこの手法では問題があります。

言語モデルでBoundingBoxを出力させることは"正しい"のでしょうか?

LLMの基本的な動作原理は次トークンの確率分布を出力させて、高い確率を持つ単語を選択するというものです。(サンプリングの説明を省きます。)

この処理方式をBounding Boxの出力に適用した場合座標の出力をする際に 例えば座標値「123.45」を出力する場合、現代の言語モデルは「123」「.」「45」といった個別のトークンを再帰的に順次予測します。(というトークナイザーがあるとします。)

この画像の例のように、次のトークン予測になるため、「1.0」の「0」を出力する時には、「1.」の次に何が来るか、ということを考えることになります。 これは従来の物体検出のモデルとは全く異なる仕組みです。 従来の物体検出モデルは直接座標を出力するように学習されます。

実はGemini Spatial Understandingでは0から1000の値で座標値を出力させることで小数点をなくし、全ての数値を一つのトークンで表しています。 つまり内部では擬似的に分類タスクになっているとも言えるかもしれません。 しかし、ここで気になるのは「物体検出タスクを分類タスクとして解くことは精度が出やすいか?」ということです。

OCR

OCR(Optical Character Recognition)とは、画像上に存在するテキストの内容を検出・認識する技術です。しかし、従来のOCRは主にテキストの文字内容の識別に特化しており、位置情報や視覚的属性の正確な把握には本質的な限界があります。 フォント属性認識における課題 OCR技術が抱える主要な問題点として、以下が挙げられます:

  1. 位置・サイズ情報の不正確性 - テキストの配置や大きさを精密に捉えることが困難
  2. フォント差異の認識限界 - フォントサイズやウェイト(太さ)の細かな違いを識別できない
  3. 視覚階層の理解不足 - デザイン上の重要度やレイアウト構造を把握できない

OCRはすでにたくさんのAPIベースのサービスとして展開されています。 しかし、これらの既存のOCRサービスを用いた実験においても、文字サイズの正確な検出において顕著な精度不足が確認されました。これは、OCR技術の根本的な設計思想が文字認識に重点を置いており、レイアウト解析には適していないことを示しています。

クリエイティブの画像内にあるテキストのフォントやフォントの色を検出するというタスクも必要です。 フォントを検出することは、クリエイティブでは色々なフォントが使われるため、対応が難しいです。 フォントカラーに関しては、理論上セグメントが100%の精度で可能であればテキストを切り取って、ルールベースで色を判定することができます。しかしそもそも先述したように、日本語のテキストに対するセグメントの精度を高めるのは難しいでしょう。

物体検出・セグメンテーション

物体検出・セグメンテーションタスクはグラウンディングと密接な関係があります。 これは位置を検出すること自体がグラウンディングと言えるからでしょう。 物体検出やセグメントに関してはこれまでたくさんの研究がされ、OSSの訓練済みのモデルも発表されてきています。 これらのモデルは一般的な物体検出タスクにおいて優れた性能を示すと考えられますが、 クリエイティブ分野での応用や複雑な推論の要求されるタスクにおいて、これらのモデルのみを用いることは以下のような理由から重要な限界を抱えています。

セグメンテーション:セグメントに関しては、例えばSegment Anything Modelのようなモデルを用いるとセグメントができますが、どのような物体へのセグメントができているかが理解できていないのでこの結果を直接利用してレイアウトの分析をするのが難しいという課題があります。

推論能力・知識量の限界 さらに、これらのモデルの課題は推論能力や知識量の不足であると考えます。 例えば、お菓子の〇〇(商品名)を宣伝するクリエイティブの画像に対して、「〇〇(商品名)の画像をセグメントして」のような固有名詞を含む指示がある場合、これらの従来のモデルは適切に対応できません。 また、「右にある三つの商品画像のうち、真ん中にある商品だけをセグメントして」といった空間的関係性や順序性を要求する複雑なクエリの処理も困難です。このような高度な推論タスクに対応するためには、言語モデルのような推論能力が必要と予想されます。

クリエイティブの画像データとしての複雑性クリエイティブ分野特有の問題として、複雑で多様なレイアウト構造があります。一般的な物体検出モデルは一般的なオブジェクトカテゴリで事前学習されているため、クリエイティブデザインの独特な要素や配置パターンに対する理解が不十分です。この学習データの偏りと実際のクリエイティブ制作現場でのニーズとの乖離が、実用性の阻害要因となっていると考えられます。

セグメントが可能なLLMモデル

LLMの推論能力とセグメントのグラウンディング能力を統合しようという取り組みが多くされています。 多数の手法がある中でもここでは2つ簡単にご紹介します。 一つ目は事前学習済みのLLMと別のセグメントができるモデルを組み合わせてLLMの出力をデコードしてセグメントにするようなアーキテクチャで、どちらのモデルも学習させる方法です。(LISA, GLaMM) 二つ目の方法として、一つ目の方法の中のマスク生成モデル(例えばSAM2)をフリーズして、LLMのみをチューニングし、最適なセグメントのマスクを得るために、マスク生成モデルに入力されるプロンプトを最適化するという手法があります。(Seg-R1, SAM-R1)

セグメントが可能なLLMの主なアーキテクチャ(かなり単純化されており、省略されていることが多いので注意してください)

弱点: 二つ目の手法に関してはこのアーキテクチャで学習させたとしてもセグメントモデル自体の能力はパラメータレベルでは変わらないことがわかります。一つ目の手法に関してはLLMの推論能力が、訓練されるOSSのLLMの能力に依存してしまいます。

Document AI

Document AIとは、書類を理解するためのAIであり、基本的には文章や画像がどこにあるかを理解することを目的としています。 例えば、LayoutParserは書類について理解することを目的としています。クリエイティブを対象としていません。 この文脈において私たちは、クリエイティブとDocumentの違いは、複雑性にあると考えています。クリエイティブでは例えば、多様なフォントが使われたり、テキストの配置に一定のルールが見られなかったりします。そのためDocument AIの対象のドキュメント、よりも「複雑」なものを対象とします。

デザインに関するエージェントの研究

既存研究デザインに対するエージェントには以下のようなものがあります。 BannerAgencyでは、デザインのデータをJSON形式で表現しLLMが生成できるようにしています。 COLEは、デザインをJSON形式で表し、そのデータ構造で、OSSのLLMモデルを訓練しています。StepbyStepで生成し、最初にレイアウト構成、画像は後から生成しています。 PosterLlamaでは、背景画像を生成した上でHTMLのような形式でテキストを生成しています。 いずれもレイアウトを詳細に深く理解して分析するというグラウンディングの話はしておらず、一般的なレイアウト生成の話をしています。

興味深い点としては、BannerAgencyではVLMを用いてフィードバックを行うプロセスを導入しています。しかしそもそもVLMが精度よく検出できる能力には限界があります。 例えば、「テキストを3px左に動かせば背景画像の顔と被らない」などといったような細かな検出は不得意である事が予想されるため、そもそもフィードバックのシグナルを生成するのが難しいという課題があります。

学習コストの問題: 一般的にこれらのAIモデルを開発するには、学習コストがかかります。 セグメンテーションのモデルや物体検出のモデルを学習するのはとてもコストがかかりますし、学習したモデルには以下の2点の問題があります

  • 精度が悪いリスクがある: 特にクリエイティブの場合には、検出対象が多様で特徴量が安定しないだろうという仮説があるため、学習に大量のデータが必要と予想される。
  • 柔軟性がなくなる: 検出するものがデータセットに依存するため、例えば新しく検出したいものが変更された時に、新たなデータセットを作成して、再学習させる必要がある。

手法

従来のAIには以上のような問題があるため私たちは独自の方法で解決しました。 従来のAIとは違い、LLM、 VLMでは抽象度が高いことが柔軟にできるようになってきています。 AIという分野の歴史において、初期の頃に可能だったことは抽象度の低いタスクでした。もしくは、抽象度が高い事象を低い次元に落とし込む、特徴量の抽出を行うことで対処してきました。 当時と比較すると、現在は自然言語の高度な質問に対応するといった抽象度がとても高いことができるようになってきています。 私たちはこの時代において、レイアウト分析のように、抽象度の低いタスクと抽象度の高いタスクを同時に行うことが必要な場合、LLM(特にクローズドなモデル)と他の専門家モデル、例えば専門性のある、物体検出のモデルを組み合わせることでゼロショット解決できる可能性があるということを提案します。

そこで、LLMモデルと物体検出のようなモデルを組み合わせるアプローチを採用しました。

End-to-Endではない方向性にした理由: 私たちが開発したAIモデルは、前述のように、一つのモデルではなく、複数のステップから成り立っています。 それに対して、AIの分野においては、End-to-Endなモデル、が存在します。 End-to-EndなAIとは、中身を全てをブラックボックス化し、単純に入力と出力のペアを用意して、一つのAIモデルを学習させることです。 End-to-Endなモデルを開発することはAIの業界において長らく行われてきました。 しかし、①現在エージェントが台頭しつつあることと、②クリエイティブの理解には様々な能力が要求される、③学習コスト削減のため、私たちはこちらの方向性をとっています。 ですが将来的にはデータセットを自動で作成するなどを行い、End-to-Endなモデルを開発することは考えています。

学習コストがゼロ: 私たちのAIの優位性は、学習なしで汎用性があることです。これは汎用性が高く、別分野への応用もしやすいことが予想できます。学習させないゼロショットの推論をするモデルであるため、例えば新しく検出したいものが増えたり、検出したくないと思った場合にすぐに対応できます。

ノイズの問題: 物体検出のようなプロンプトエンジニアリングのような即時性のある調整の効かないモデルの弱点は、 時々異常なノイズを出力することです。 このノイズを含んだままその後のプロセスに進むとその後のプロセスに大きく影響します。 一般的にこのようなノイズを修正したい場合にはモデルを学習しなければなりません。 それと比較してLLM・VLMと組み合わせる場合は、「プロンプトエンジニアリング」を用いることで時間をかけずに学習なしで出力を制御できるという利点があります。 そのため組み合わせることで専門的なモデルで出力されたノイズを、VLM側で「プロンプトエンジニアリング」を通して吸収できるという利点があります。

以下に他のモデルとの違いを簡単に図にしたものです。定量的なものではないので参考程度にしていただければと思います。

私たちはさまざまな手法を検証したうえでプロダクトに実装しました。 今回は私たちが開発している中でも簡単な例として、いくつかの事例を紹介します

結果

以上の考え方を応用して、私たちはさまざまな手法を提案・開発し、プロダクトに実装しています。 今回は私たちが開発している中でも簡単な例として、いくつかの事例を紹介します。 (技術保護の観点から詳しい方法はお伝えすることができないことをご了承ください。)

画像要素の検出

画像変数とはクリエイティブの中で入れ替えられる素材、のことです。 例えば、この猫のクリエイティブにおいては、他のフェス、例えば、犬のフェスティバルなどを宣伝する場合には、「猫の画像」は犬の画像に入れ替える必要があります。 これを見つけるためには大きく二つの要素が重要です。 ①VLMなどの推論能力を用いて変数となる物体を認識して、 ②グラウンディングできるモデルを用いて位置を特定する必要があります。

私たちは以下の図に示されるように、LLMだけではなく従来の検出モデルを用いて、LLMの推論能力と物体検出系のモデルのグラウンディング能力を組み合わせる手法を提案しました。

実際の結果

こちらの結果を見ると画像変数となる箇所を自動で判断して、検出を行うことができていることがわかります。

以下のように複雑な「推論」能力と、どこにあるかという「グラウンディング」が必要とされます。

この猫のクリエイティブにおいて難しいのは どこを検出すべきか、という点です。 例えば、右上のリボンの装飾だけを検出対象として認識して、 他の丸の装飾などは変数ではなく、背景画像として認識したいという気持ちがあります。 そのため「高度な推論能力」が必要とされるのです。

このクリエイティブの場合は、人・手持ち扇風機・バックなどを認識するのではなく 右側にある画像を人まとまりに変数としたいのであっています。

私たちの開発しているAIの特徴として「ほぼプロンプトエンジニアリングのみで検出対象を柔軟に変えることができる」があります。例えば、上のクリエイティブで顔や扇風機を検出したいような要件が出てきた場合に、モデルを再学習させることなく」、プロンプトエンジニアリングのみで要件変更に対応できるという強みがあります。

テキストの位置の検出

テキストの位置を検出できる低レベルのモデルとVLMを組み合わせました。 検出モデルを用いてVLMの能力を補完し、その過程で起きたノイズをVLMで吸収するという手法です。 OCRやその他検出系のモデルは特にノイズが出やすいです。 前述した通り、それらのノイズをVLMなどのモデルでうまく吸収するという方針になっています。

実際の結果

まだ改善途中ではあるもののそれぞれの文字に対して精度よくbounding boxが検出できていることがわかります。

今後は定量的に評価できる実験を行っていく予定です。


これからのAI開発に重要かもしれないこと

LLM時代のAI開発

現代のAI開発において、私たちは「抽象度ドリブン開発(Abstraction-Driven Development)」という名前を提案したいと思います。これは、独立したモデルを用いて低レベルのタスクを高精度で処理し、LLM/VLMのタスクと明確に分離することに焦点を当てた開発手法です。 LLMには得意分野と苦手分野が明確に存在します。例えば、文章の感情分析や内容理解は非常に得意ですが、文字数を正確に数えるような単純な作業は意外にも苦手としています。数学の問題かどうかを判定することはできても、実際に数式を解くことになると精度が落ちる傾向にあります。 日常的な推論においても同様の傾向が見られます。「喉が渇いたから水が欲しい」という論理的な推論は得意でも、実際に水を取りに行くためにロボットのモータをどの程度動かすべきかという具体的な制御信号を出力するのは困難です。クリエイティブな領域でも、商品画像の存在を認識することはできても、その画像が画面上のどの位置にあるかを正確に特定することは課題となります。 理想的には、ある単一のモデルですべての課題を解決できれば素晴らしいことでしょう。実際に、近い将来にはそのような汎用的なモデルが登場する可能性も十分にあります。現在もLLMにグラウンディング能力を付与する研究は活発に行われており、着実に進歩を遂げています。 しかし現実的には、まだ多くの困難なタスクが残されているのが現状です。この課題の根本的な原因は、現在のAIが言語という抽象的で処理しやすい文脈に特化して発展してきたため、物理的な世界との対応関係(グラウンディング)が必要な文脈との親和性が低いことにあると考えられます。 そこで私たちが提案したいのは、目の前のタスクに取り組む際に「これは言語の文脈で解くべき問題なのか?」という視点から問題を見直すことです。この問いかけによって、より適切なアプローチを選択し、効率的な解決策を見出すことができるのではないでしょうか。

Tool-Driven Development(ツールドリブン開発)

私たちは、このエージェントの時代におけるAI開発の新たな開発方針としてさらに「Tool-Driven Development」を考案しました。 従来のアプローチでは、複雑なタスクを一つの大きなE2Eモデルで解決しようとしていました。私たちが提案する手法では、「最終的に実現したい複雑なタスクを小さな単位に分解し、それぞれのタスクに特化したAIモデルを開発することで、最終的に高度な機能を持つエージェントを構築する」ことを目指します。 具体例として、私たちのネオデザインAIプロジェクトでは、「クリエイティブに特化した物体検出モデル」を独立したAIモデルとして開発し、それをエージェントがツールとして活用することで、より高度な機能を持つエージェントの開発が可能になると考えています。 このアプローチにより、各コンポーネントの専門性を高めつつ、全体としてより柔軟で拡張性の高いAIシステムを構築することができます。

"LLMで何でもできる時代”のAIエンジニア生存戦略

昨今、生成AIの進化は本当に目覚ましく、従来は専門的な知識や技術を必要としていた様々なタスクが、誰でも気軽に取り組めるような時代になってきているように思います。文章を書いたり、画像を作ったり、プログラムを組んだりといったことが、生成AIを使えば驚くほど簡単にできるようになっています。 ただ、この記事でお話ししてきたように、言語や画像の理解においてLLMが素晴らしい能力を見せてくれる一方で、現実世界の物理的な部分や具体的な制御との間には、まだまだギャップがあるのが実情かもしれません。 このギャップこそが、AIエンジニアの皆さんにとって腕の見せどころになるのではないでしょうか。LLMが中心となっている今の時代だからこそ、あえてLLM以外の技術やアプローチを上手に使って、LLMではカバーしきれない部分を補っていく。そんなスキルが、これからのAIエンジニアには重要になってくるかもしれません。 LLMを使いこなすだけでなく、その得意不得意をしっかりと理解して、必要に応じて他の技術と組み合わせながら、より実用的で信頼できるAIシステムを作り上げていく。AI技術がどんどん身近になっていく中でも、そういった専門的な視点と技術力こそが、エンジニアとしての価値を保ち続ける鍵になっていくのかもしれません。


採用情報

Algomaticでは現在積極的に採用活動を行っています。

jobs.algomatic.jp


著: Shure, 実験:Ootsuka