2026-02-28

ClaudeCodeで業務効率化！SlackBotでAIネイティブへ

はじめに

株式会社Algomatic AXカンパニーの大塚です。 AXではエンタープライズ企業様向けのAI導入支援を行っています。

今回は、Claude Codeを活用してAX独自のSlack Botを作成し、社内業務の効率化に取り組んでいる事例をご紹介します。

作成した背景と理由

SlackにはClaudeやSlack AIといったAI機能がすでに存在しますが、実際に使用する中でいくつかの課題がありました。

具体的には、Slackのログを参照して回答を生成するところまでは対応できるものの、そこから先の「取得したデータを活用した具体的な作業」にはまだ対応しづらいと感じています。

また、当初はSlack Botではなく、WebアプリケーションやChromeの拡張機能なども検討していました。しかし、社内で最も自然に利用できる形を考えたときにSlack Botが最も利用しやすい形態であると判断したため、今回はSlack Botで進めることにしました。

構成・アーキテクチャ

インフラ構成

Slack Botの構成としては、GCP上にClaude Agent SDKを用いたBotを稼働させています。イベントトリガー方式を採用しており、メンションがなければ動作しないサーバーレス的な設計にしています。シンプルな構成で運用コストを抑えられる点を重視し、この構成を採用しました。

Claude Agent SDKの採用理由

エージェントの実装にClaude Agent SDKを採用した理由は、現時点で拡張性が高く、今後のアップデートも期待できる点を考慮したためです。エージェントには画像生成やSlackのデータ取得といった必要なツールを追加し、Slack Botとしての機能を拡張しています。現在も継続的に改善中です。

Bot型エージェントの設計

動作方式としては、Botを@メンションすることで起動するBot型エージェントとして設計しています。スラッシュコマンドによるワークフロー型を採用しなかった理由は、定型的なワークフロー型にしてしまうと汎用性が失われ、便利さが薄れてしまう懸念があったためです。エージェントとして動作させることで、柔軟な対応を可能にしています。

現時点で実装している機能

現在、以下の機能を実装しています。

画像生成
Web検索
チャンネル検索
スレッド検索
資料の解析

これらの機能を組み合わせることで、指定した期間のチャンネルサマリーの作成、サマリー内容の画像化、Slack上からのWeb検索、資料をもとにしたディスカッション支援など、さまざまなタスクに対応できます。

もちろん、現時点ではまだ汎用的なタスクすべてをカバーできているわけではありません。今後は、有益な知見をDBに蓄積するナレッジ収集機能、定期実行によるニュース投稿、スライドのたたき台作成といった機能を順次追加し、より実用的なBotへと発展させていく予定です。

リリース結果と動作の紹介

社内公開後、想定していた以外の活用方法も見られました。初回リリースということもあり使用頻度はまだ十分とは言えないため、機能の拡充を通じて利用頻度の向上を目指しています。下記画像はSlackBotが動作している一例です。

まとめ

社内で日常的にやりとりされるチャットを自然にナレッジとして蓄積すること、そしてAIを活用するまでの導線を限りなくゼロに近づけること。これらが実現できれば、より効率的な業務遂行が可能になると考えています。

Claude Codeのようなツールにより開発の幅が広がっていますが、自社の業務に合わせた細かな対応は、自ら作らなければ実現できないのも事実です。便利な仕組みは積極的に活用しつつ、既存のツールではどうしても対応できない部分をエンジニア自身が見つけて解決していく。今回のSlack Bot作成は、そうした姿勢の重要性を改めて実感する機会となりました。

これからのエンジニアには、能動的に課題を発見する力がますます求められると感じています。引き続き、社内の煩雑な業務をAIで解決していくと同時に、Botの利用状況の可視化や不具合検知の仕組みなど、運用面の整備も行いAIネイティブ組織として進化をしていきます。

2026-01-28

コンテキストエンジニアリングの歴史：RAGの過去から現在をたどる

こんにちは、Algomatic AXカンパニー所属の大塚です。

本日は、LLMアプリケーション開発に欠かせない技術となったRAG（Retrieval-Augmented Generation：検索拡張生成）について、その誕生から最新動向までを論文とともに振り返っていきたいと思います。

RAGは2020年に提案されて以来、様々な改良が加えられてきました。単純な検索と生成の組み合わせから始まり、自己反省機構の追加、グラフベースの構造化、エージェント型アーキテクチャへと進化しています。そして現在、RAGは「コンテキストエンジニアリング」というより広い概念の一部として位置づけられています。

今回の記事では、RAGを全体像から理解することを目的として、13本の主要論文とともにその歴史を時系列でたどっていきます。

この記事のサマリー

2020年：REALM、DPRが検索と言語モデル統合の基盤を作り、RAG原論文が「検索拡張生成」の概念を定義
2022-2023年：HyDE（クエリ拡張）、FLARE（能動的検索）、Self-RAG（自己反省）により検索精度と生成品質が向上
2024年：CRAG（検索結果の訂正）、Adaptive-RAG（動的戦略選択）、GraphRAG（知識グラフ活用）、Modular RAG（モジュール設計）で高度化
2025年以降：エージェント型RAG、マルチモーダルRAGへと広がる。LLMアプリ開発の視点も「コンテキストエンジニアリング」という広い枠組みへ

前史・基盤技術（2020年）

RAGが登場する前に、その基盤となる技術が2つ発表されました。検索と言語モデルを統合するというアイデアは、これらの研究から始まっています。

REALM：検索を事前学習に統合

項目	内容
論文タイトル	REALM: Retrieval-Augmented Language Model Pre-Training
著者/組織	Kelvin Guu, Kenton Lee, Zora Tung, Panupong Pasupat, Ming-Wei Chang / Google Research
発表時期	2020年2月
arXiv	https://arxiv.org/abs/2002.08909

主要な貢献・技術的特徴

REALMは、言語モデルの事前学習段階で検索機能を統合した研究です。従来の言語モデルは、モデルのパラメータ内に知識を暗黙的に記憶していました。しかし、この方法では知識の更新が困難であり、膨大なパラメータ数が必要になるという問題がありました。

REALMは以下のアプローチを提案しました。

Knowledge Retriever（知識検索器）：入力テキストに関連する文書をコーパスから検索します
Knowledge-Augmented Encoder（知識拡張エンコーダ）：検索された文書を入力と組み合わせて処理します
End-to-end学習：検索器とエンコーダを同時に学習し、最適化します

ポイントは、検索操作を微分可能にすることで、誤差逆伝播法による学習を可能にした点です。「どの文書を検索すべきか」をモデルが自動的に学習できるようになりました。

RAGの進化における位置づけ

REALMは、「検索と言語モデルの統合」という方向性を示した研究です。後のRAGアーキテクチャの設計でも参考にされており、事前学習段階での検索統合という考え方はここから来ています。

Dense Passage Retrieval（DPR）：密ベクトル検索の基盤

項目	内容
論文タイトル	Dense Passage Retrieval for Open-Domain Question Answering
著者/組織	Vladimir Karpukhin, Barlas Oguz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, Wen-tau Yih / Facebook AI Research
発表時期	2020年4月
arXiv	https://arxiv.org/abs/2004.04906

主要な貢献・技術的特徴

DPRは、オープンドメイン質問応答タスクにおいて、BERTベースの密ベクトル（Dense Vector）による検索手法を提案しました。

従来の検索システムは、TF-IDFやBM25といった疎ベクトル（Sparse Vector）ベースの手法が主流でした。これらは単語の出現頻度に基づく手法であり、同義語や言い換え表現に弱いという欠点がありました。

DPRは以下の特徴を持っています。

Dense Encoder構造：クエリと文書をそれぞれ独立したBERTエンコーダで埋め込みベクトルに変換します
In-batch negatives learning：学習時に同一バッチ内の他のサンプルを負例として使い、効率的に学習します
FAISS統合： Facebookが開発した高速類似検索ライブラリFAISSとの組み合わせで、大規模コーパスでも実用的な速度で検索できます

実験では、Natural QuestionsやTriviaQAなどのベンチマークで、BM25を大幅に上回る性能を示しました。

RAGの進化における位置づけ

DPRは、現代のRAGシステムにおける検索コンポーネントの代表的な手法です。密ベクトル検索が有効であることを示し、後続の多くの研究がDPRをベースラインとして使っています。

RAGの誕生（2020年）

RAG原論文：用語と概念の確立

項目	内容
論文タイトル	Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
著者/組織	Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, Douwe Kiela / Facebook AI Research, University College London, New York University
発表時期	2020年5月（NeurIPS 2020で発表）
arXiv	https://arxiv.org/abs/2005.11401

主要な貢献・技術的特徴

この論文は、RAG（Retrieval-Augmented Generation）という用語を生み出し、検索拡張生成の概念を整理しました。

RAGは、事前学習済み言語モデルが持つパラメトリックメモリと、外部知識ベースによるノンパラメトリックメモリを組み合わせるハイブリッドアーキテクチャです。

論文では2つのバリエーションが提案されました。

RAG-Sequence：検索された同一の文書を使用して完全な出力シーケンスを生成します
RAG-Token：各出力トークンの生成時に、異なる文書からの情報を参照できます

技術的な構成要素は以下です。

検索器（Retriever）： DPRをベースとした密ベクトル検索
生成器（Generator）： BART（Bidirectional and Auto-Regressive Transformers）を使用
Marginalization：検索された複数の文書からの情報を確率的に統合

RAGの進化における位置づけ

この論文は、RAG研究の出発点です。後続の多くの研究がこの論文を参照しています。「検索して生成する」というシンプルな考え方を示し、知識集約型タスクにおける新しいアプローチを提案しました。

事前学習済みモデルの知識を外部データベースで補完できることを示した点がポイントです。モデルの再学習なしに知識を更新できるようになりました。

検索拡張の広がり（2022-2023年）

RAGの基本概念ができた後、検索の質と生成の精度を高めるための様々なアプローチが研究されました。

HyDE：仮説的文書による検索改善

項目	内容
論文タイトル	Precise Zero-Shot Dense Retrieval without Relevance Labels
著者/組織	Luyu Gao, Xueguang Ma, Jimmy Lin, Jamie Callan / Carnegie Mellon University, University of Waterloo
発表時期	2022年12月
arXiv	https://arxiv.org/abs/2212.10496

主要な貢献・技術的特徴

HyDE（Hypothetical Document Embeddings）は、ゼロショット検索の問題を解決する手法です。

従来のDPRなどの密ベクトル検索は、大量のラベル付きデータで学習する必要がありました。しかし、新しいドメインでは適切な学習データが存在しないことが多く、性能が低下するという問題がありました。

HyDEは以下のアプローチでこの問題を解決します。

HyDE：ユーザーのクエリに対して、LLM（InstructGPT）が「理想的な回答を含む文書」を生成します
Embedding：生成された仮説的文書をContrieverで埋め込みベクトルに変換します
Dense Retrieval：仮説的文書の埋め込みを使って、実際の文書コーパスを検索します

この手法のポイントは、クエリと文書の「表現のギャップ」を仮説的文書で埋めることです。質問形式のクエリは、回答を含む文書とは表現が大きく異なります。HyDEは、LLMに回答を生成させて、検索対象の文書に近い表現を得ます。

RAGの進化における位置づけ

HyDEは、LLMを使ったクエリ拡張（Query Expansion）という方法を示しました。検索精度を上げるためにクエリ自体を工夫するというアイデアは、後の研究でも使われています。

また、LLMを検索の前処理に使うという発想は、RAGパイプライン全体を最適化する流れにつながっています。

FLARE：能動的な前向き検索

項目	内容
論文タイトル	Active Retrieval Augmented Generation
著者/組織	Zhengbao Jiang, Frank F. Xu, Luyu Gao, Zhiqing Sun, Qian Liu, Jane Dwivedi-Yu, Yiming Yang, Jamie Callan, Graham Neubig / Carnegie Mellon University, Meta AI
発表時期	2023年5月
arXiv	https://arxiv.org/abs/2305.06983

主要な貢献・技術的特徴

FLARE（Forward-Looking Active REtrieval augmented generation）は、生成プロセス中に動的に検索を行う能動的検索手法です。

従来のRAGは、生成の開始前に一度だけ検索を行う「ワンショット検索」でした。しかし、長文生成タスクでは、生成が進むにつれて新しい情報が必要になることがあります。

FLAREは以下の仕組みで能動的な検索を行います。

Confidence-based trigger： LLMが生成する各トークンの確率を監視し、低信頼度のトークンが出現した際に検索をトリガーします
Forward-looking retrieval：次に生成される内容を予測し、その予測に基づいてクエリを生成します
Iterative generation and retrieval：検索結果をコンテキストに追加し、生成を継続します

具体的には、LLMに「次の文」を一時的に生成させ、その文をクエリとして検索を行います。検索結果を得た後、その情報を使って実際の生成を行います。

RAGの進化における位置づけ

FLAREは、適応的検索（Adaptive Retrieval）の概念を提案しました。「いつ検索すべきか」「何を検索すべきか」を動的に判断するという考え方は、後のSelf-RAGやAdaptive-RAGに引き継がれています。

また、長文生成タスクにおけるRAGの適用範囲を広げ、単純な質問応答を超えた応用が可能になりました。

Self-RAG：自己反省による品質向上

項目	内容
論文タイトル	Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
著者/組織	Akari Asai, Zeqiu Wu, Yizhong Wang, Avirup Sil, Hannaneh Hajishirzi / University of Washington, IBM Research, Allen Institute for AI
発表時期	2023年10月
arXiv	https://arxiv.org/abs/2310.11511

主要な貢献・技術的特徴

Self-RAGは、LLMが自身の検索と生成プロセスを自己反省（Self-Reflection）できるようにした研究です。

従来のRAGには、以下の問題点がありました。

検索が常に有益とは限らない（関係のない情報を取得することもある）
検索結果の品質を評価する仕組みがない
生成された回答の正確性を検証できない

Self-RAGは、特殊な反省トークン（Reflection Token）を導入することでこれらの問題に対処します。

反省トークンには以下の種類があります。

トークン	役割
Retrieve	検索が必要かどうかを判断
ISREL	検索結果がクエリに関連しているか評価
ISSUP	生成内容が検索結果に支持されているか評価
ISUSE	生成内容がユーザーにとって有用か評価

Self-RAGのモデルは、生成時にこれらの反省トークンを出力し、自身の出力を批評しながら生成を進めます。推論時には、反省トークンのスコアに基づいて、複数の候補から最適な出力を選択できます。

RAGの進化における位置づけ

Self-RAGは、RAGシステムに自己評価能力を持たせた研究です。「検索すべきか否か」「生成結果は信頼できるか」をモデル自身が判断できるようになりました。

この自己反省メカニズムは、後のCRAGやAgentic RAGの設計にも取り入れられています。また、推論時に品質と引用の厳密さのバランスを調整できる点も使いやすいです。

高度なRAG手法（2024年）

2024年に入ると、RAGの研究は多様化しました。検索品質の向上、動的な戦略選択、構造化された知識の利用、モジュラー設計へと広がっています。

CRAG：検索結果の訂正メカニズム

項目	内容
論文タイトル	Corrective Retrieval Augmented Generation
著者/組織	Shi-Qi Yan, Jia-Chen Gu, Yun Zhu, Zhen-Hua Ling / University of Science and Technology of China, UCLA, Google Research
発表時期	2024年1月
arXiv	https://arxiv.org/abs/2401.15884

主要な貢献・技術的特徴

CRAG（Corrective Retrieval Augmented Generation）は、検索結果の品質を評価し、必要に応じて訂正を行う仕組みを導入しました。

CRAGの中核は、軽量な検索評価器です。この評価器は、検索された文書がクエリに対して「正しい」「曖昧」「誤り」のいずれかを判定します。

判定結果に応じて、以下のアクションが取られます。

判定	アクション
正しい	検索結果をそのまま使用し、知識精製で重要部分を抽出
曖昧	検索結果とWeb検索の両方を組み合わせて使用
誤り	検索結果を破棄し、Web検索で新たな情報を取得

知識精製のプロセスでは、検索された文書を細かい単位に分解し、関連性の高い部分のみを抽出します。無関係な情報によるノイズを減らすためです。

RAGの進化における位置づけ

CRAGは、検索結果の品質管理を扱った研究です。従来のRAGでは、検索結果をそのまま使用していたため、検索ミスがそのまま生成品質の低下につながっていました。

CRAGの「評価→訂正」というパターンは、安定したRAGシステムを作るときに使えます。Web検索をフォールバックとして使うアイデアも実用的です。

Adaptive-RAG：クエリに応じた動的戦略

項目	内容
論文タイトル	Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity
著者/組織	Soyeong Jeong, Jinheon Baek, Sukmin Cho, Sung Ju Hwang, Jong C. Park / KAIST
発表時期	2024年3月
arXiv	https://arxiv.org/abs/2403.14403

主要な貢献・技術的特徴

Adaptive-RAGは、クエリの複雑度に応じて最適な検索戦略を動的に選択する手法です。

すべてのクエリに同じRAG戦略を適用することは非効率です。簡単な質問にはシンプルなアプローチで十分であり、複雑な質問には高度な処理が必要です。

Adaptive-RAGは、クエリを3つの複雑度レベルに分類します。

レベル	説明	戦略
Level A	簡単なクエリ（LLMの知識で回答可能）	検索なしで直接生成
Level B	中程度のクエリ（1回の検索で回答可能）	シングルステップRAG
Level C	複雑なクエリ（複数回の検索・推論が必要）	マルチステップRAG（反復的な検索と推論）

クエリの複雑度を判定するために、小規模な分類器を学習させます。この分類器の学習には、様々なデータセットから自動的にラベルを生成する手法を用います。

RAGの進化における位置づけ

Adaptive-RAGは、計算効率と精度のバランスをとる方法を示しました。すべてのクエリに重い処理を適用する必要はなく、必要に応じてリソースを割り当てるという考え方は実用的です。

また、クエリの複雑度を自動的に判定する方法も提案しており、後の研究でも参照されています。

GraphRAG：知識グラフによる構造化検索

項目	内容
論文タイトル	From Local to Global: A Graph RAG Approach to Query-Focused Summarization
著者/組織	Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Jonathan Larson / Microsoft Research
発表時期	2024年4月
arXiv	https://arxiv.org/abs/2404.16130

主要な貢献・技術的特徴

GraphRAGは、知識グラフ（Knowledge Graph）を使ってRAGの検索精度を高める手法です。

従来のベクトル検索ベースのRAGには、以下の限界がありました。

局所的な情報のみを取得し、全体的な文脈を捉えにくい
エンティティ間の関係性を明示的に扱えない
「データセット全体についての質問」に弱い

GraphRAGは、以下のプロセスで知識グラフを構築・利用します。

エンティティ抽出： LLMを使用して文書からエンティティと関係を抽出
グラフ構築：抽出された情報から知識グラフを構築
コミュニティ検出：グラフをクラスタリングし、階層的なコミュニティ構造を特定
コミュニティ要約：各コミュニティについてLLMで要約を生成
検索と生成：クエリに関連するコミュニティ要約を検索し、回答を生成

グローバルな質問（例：「このデータセットの主要なテーマは何か」）に対応できる点がポイントです。コミュニティ要約を使うことで、データセット全体を見た回答ができます。

RAGの進化における位置づけ

GraphRAGは、構造化された知識表現をRAGに取り入れた研究です。ベクトル検索だけでは捉えられない、エンティティ間の関係性や階層構造を使えるようになりました。

Microsoftが提供するGraphRAGの実装は、オープンソースとして公開されており、実際の業務システムへの適用も進んでいます。

Modular RAG：モジュール式の柔軟な組み立て

項目	内容
論文タイトル	Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks
著者/組織	Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, Yi Dai, Jiawei Sun, Meng Wang, Haofen Wang / Tongji University, Fudan University
発表時期	2024年7月
arXiv	https://arxiv.org/abs/2407.21059

主要な貢献・技術的特徴

Modular RAGは、RAGシステムをモジュール化し、部品を組み替えるように柔軟に構成できるフレームワークを提案しています。

RAGの研究が進むにつれ、様々な手法が提案されてきましたが、それらを整理・比較することが難しくなっていました。Modular RAGは、RAGシステムを6つの主要モジュールに分解します。

モジュール	役割
Indexing（インデクシング）	文書のチャンキング、埋め込み、インデックス構築
Pre-retrieval（検索前処理）	クエリ拡張、クエリ変換、クエリルーティング
Retrieval（検索）	ベクトル検索、キーワード検索、ハイブリッド検索
Post-retrieval（検索後処理）	リランキング、フィルタリング、圧縮
Generation（生成）	プロンプト構築、LLMによる回答生成
Orchestration（オーケストレーション）	各モジュールの制御フロー管理

各モジュール内には複数のサブモジュール（オペレーター）が存在し、用途に応じて組み合わせを変更できます。たとえば、検索前処理としてHyDEを使うか、クエリ分解を使うかを選択できます。

RAGの進化における位置づけ

Modular RAGは、RAG研究を整理し、統一的なフレームワークを提案しました。メリットは以下です。

既存手法の分類と比較がしやすくなった
新しい手法の位置づけがわかりやすくなった
実装時のアーキテクチャ設計の参考になる

この論文は、RAGが単一の技術から、複数のコンポーネントを組み合わせたパイプライン設計へと変わってきたことを示しています。

項目	内容
論文タイトル	Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG
著者/組織	Aditi Singh, Abul Ehtesham, Saket Kumar, Tala Talaei Khoei
発表時期	2025年1月
arXiv	https://arxiv.org/abs/2501.09136

タイプ	説明
単一エージェント型	1つのエージェントがすべての処理を担当
マルチエージェント型	複数の専門エージェントが協調して処理
階層型	エージェントが階層構造を持ち、上位が下位を制御

項目	内容
論文タイトル	A Survey of Multimodal Retrieval-Augmented Generation
著者/組織	Lang Mei, Siyu Mo, Zhihan Yang, Chong Chen
発表時期	2025年4月
arXiv	https://arxiv.org/abs/2504.08748

課題	説明
モダリティ間のアラインメント	異なるモダリティの情報を統一的な埋め込み空間にマッピング
クロスモーダル検索	テキストクエリで画像を検索、画像クエリでテキストを検索など
マルチモーダル融合	複数モダリティからの情報を統合して生成

項目	内容
論文タイトル	A Survey of Context Engineering for Large Language Models
著者/組織	Lingrui Mei, Jiayu Yao, Yuyao Ge 他
発表時期	2025年7月
arXiv	https://arxiv.org/abs/2507.13334

要素	説明
システムプロンプト	LLMの振る舞いを定義する指示
具体例の提示	タスクの例示（Few-shot）
検索された知識	RAGによる外部知識（従来のRAG）
ツール定義	利用可能なツールの定義
対話履歴	過去の対話履歴
作業メモリ	エージェントの作業メモリ
ユーザー情報	ユーザーの属性や過去の行動履歴

まとめ：RAGの進化とこれから

本記事では、2020年のRAG誕生から2025年のコンテキストエンジニアリングへの位置づけまで、主要な論文とともに振り返りました。

RAGの進化の軌跡

時期	フェーズ	主要論文	キーワード
2020年2月	前史・基盤技術	REALM	検索を事前学習に統合
2020年4月		DPR	密ベクトル検索の基盤
2020年5月	RAGの誕生	RAG原論文	用語と概念の確立
2022年12月	検索拡張の広がり	HyDE	仮説的文書による検索改善
2023年5月		FLARE	能動的な前向き検索
2023年10月		Self-RAG	自己反省による品質向上
2024年1月	高度なRAG手法	CRAG	検索結果の訂正メカニズム
2024年3月		Adaptive-RAG	クエリに応じた動的戦略
2024年4月		GraphRAG	知識グラフによる構造化検索
2024年7月		Modular RAG	モジュール式の柔軟な設計
2025年1月	新しいパラダイム	Agentic RAG Survey	エージェント型RAGの台頭
2025年4月		Multimodal RAG Survey	テキストを超えた検索拡張
2025年7月		Context Engineering Survey	コンテキストエンジニアリングの整理

今後の展望

RAGは今後も改良が続くと思います。今後の方向性としては以下があります。

エージェントとの統合： RAGはエージェントの「記憶」として機能し、より自律的なシステムの一部になっていく
マルチモーダル対応：テキスト以外のモダリティを扱うことが当たり前になる
効率性の改善：長いコンテキストウィンドウを効率的に使う技術が進む
評価手法の整備： RAGシステムの品質を定量的に評価する方法が整っていく

RAGは単なる技術的手法から、LLMアプリケーション開発における基本的な設計パターンになりました。コンテキストエンジニアリングというより広い枠組みの中で、RAGの知見は今後も使われていくと思います。

一緒に働きませんか？

Algomatic AXカンパニーでは、RAGやLLMアプリケーション開発に興味のあるエンジニアを募集しています。興味のある方はぜひご応募ください。

algomatic.notion.site

2025-12-27

自然言語だけでWorkFlowが完成する時代: WorkFlow DevOpsへの変革

こんにちは。Algomaticの大塚です。
今回はDifyやn8nといったAIアプリケーションのWorkFlowを自動で作成する取り組みをご紹介します。

はじめに：ノーコードツールの限界

Dify、n8nといったノーコードツールは非エンジニアでも触れる点がプログラミングとの違いと言われています。しかし、実務の観点から見ると状況は異なります。

プロンプトを1行変更するだけでも、GUIの操作手順を覚える必要がある
作ったWorkFlowのテストは手動でやるしかない
エラーが起きたら、どこが悪いのか特定するのに時間がかかる

結局、非エンジニアでも触れるはずのツールが、専門知識を持った人しか運用できない矛盾が生まれています。

社内の取り組み

そんな課題を解決するために、社内でWorkFlowを自動で生成するシステムを開発しています。このシステムは自然言語からWorkFlowを自動生成するツールです。

ユーザーが実現したい内容を自然言語で伝えるとWorkFlowの作成から動作確認までAIエージェントがE2Eで実施します。これにより品質の担保がされたWorkFlowを高速で作成することが可能になりました。

仕組み

このシステムのアーキテクチャは、3つのAIエージェントによるプロセスで構成されています。

各エージェントの役割

プロセス	役割	詳細
作成	WorkFlow生成	仕様をプロンプトに含め、LLMでWorkFlowを生成。Difyインポート可能な形式かチェック。作成されたWorkFlowをDify上で実際にテスト実行。
蓄積	結果判定	テスト結果をAIに渡し、正しく動作しているか判定。エラー内容はIssueに蓄積
改善	エラー修正	失敗時にエラー内容を分析しWorkFlowを修正

品質を担保する3つの自動化

このシステムでは、WorkFlowの品質を担保するために3つの自動化を実装しています。

1. WorkFlowを作成前後でバリデーションチェック

作成されたWorkFlowがコード上で問題ないか、作成の前後でバリデーションチェックを実施します。

作成前チェック：仕様書の構文検証、必須パラメータの存在確認
作成後チェック：構文エラー検出、形式の検証、Difyとの互換性確認

実行前に検出できるエラーは実行前に潰す方針を徹底しています。

2. ブラウザテストとLLM-as-a-Judge

WorkFlowをDifyにインポートした後、ブラウザ自動化ツールで実際にテストを実行。テスト結果はLLM-as-a-Judgeで判定します。

テスト実行時の画面とDOM情報を取得
定義された仕様を成功基準と一緒にLLMに渡す
LLMがこのWorkFlowは仕様を満たしているかを判定

人の目で見て判断するような曖昧な基準も、LLMなら自然言語で表現できます。

3. 改善点のIssue化と継続的な改善

判断された結果、改善点がある場合はGitHub Issueを自動で作成し、ログを残しつつ改善を進めます。

エラー内容を記録：何が起きたか、どのステップで失敗したか、スクリーンショットを含めて記録
修正の履歴：どのIssueに対してどの修正が行われたかを追跡可能
ナレッジの蓄積：過去の失敗パターンと解決策がIssueとして蓄積され、将来の改善に活用

このサイクルにより、作って終わりではなく継続的に品質を高めていく仕組みを実現しました。
※以下は作成できたDifyのワークフロー例です

WorkFlow DevOpsの特徴

このシステムの特徴は、AIを使ってAIアプリケーションを自動で改善し続ける仕組みです。

LLMによる自動テスト・自動判定

従来のテスト自動化では、正解を事前に定義する必要がありました。しかしDifyなどLLMを介したWorkFlowの出力の多くは自然言語であり、正解を厳密に定義しづらい場面が多いです。

そこで、このシステムではLLM-as-a-Judgeを採用しました。テスト結果の画面とDOM情報をLLMに渡し、このWorkFlowは仕様を満たしているかを判定させます。人が目で見て判断するような曖昧な基準も、自然言語で表現できるためLLMなら対応可能です。これにより、テスト設計のボトルネックを解消できます。

2つの改善サイクル

このシステムには2つの改善サイクルがあります。

1. 完全自律型サイクル

作成→インポート→テスト→AIで判定→修正のサイクルを、成功するまで自動で回します。

失敗したらその場で修正し、成功するまでリトライする。人の介入なしにリアルタイムで品質を高めていく、まさにAIネイティブな開発プロセスです。

2. 人を介した継続的な改善サイクル

自動の修正で解決できなかった問題は、GitHub Issueとして起票されます。

エラーの種類や発生箇所に応じたIssueを自動で作成
エラー内容、画面キャプチャ、ログへの参照を記録
開発者がレビューし、手動で修正・改善
過去の失敗パターンと解決策がナレッジとして蓄積

自動で解決できる問題は自動で、人の判断が必要な問題は明確に可視化する。2つのサイクルが連携し、継続的に品質を高めていく仕組みです。

高速な仮説検証

AIの進化速度は驚異的で、新しいモデルが出るたびにプロンプトの書き方も変わり、ベストプラクティスも更新されます。

従来の開発プロセスでは、この変化についていくのが難しくなっています。しかしこのシステムなら、仮説を自然言語で書いてすぐに検証できます。

このプロンプトで精度が上がるか試してみよう
新しいモデルに切り替えたら動くか確認しよう
エラーハンドリングを追加したらどうなるか見てみよう

こうした仮説をすぐに検証できるため、AIの進化速度に追従しながら品質を担保できます。

Issueを活用したコンテキストエンジニアリング

このシステムの特徴は、蓄積されたIssueがAIの改善コンテキストになる点です。

従来のAI開発では、プロンプトに含める情報を人が都度設計する必要がありました。しかしこのシステムでは、過去の失敗パターンと解決策がGitHub Issueとして構造化されて蓄積されます。

失敗パターンを自動で分類：どのステップで、どんなエラーが発生したかを記録
解決策の紐付け：各Issueに対してどの修正が有効だったかを追跡
コンテキストの自動注入：エージェントが類似のIssue履歴を参照して修正の方針を決定

これにより、AIが過去の経験を踏まえて判断できるようになります。人が毎回プロンプトを調整しなくても、システムが自律的に学習していく。コンテキストエンジニアリングとしての工夫も取り入れました。

AIと人の分担アーキテクチャ

WorkFlow DevOpsでは、AIと人の役割を明確に分離しています。

AIが担当する領域

WorkFlowの自動生成
形式チェック・バリデーション
ブラウザテストの実行と結果取得
LLM-as-a-Judgeによる成否判定
軽微なエラーの自動修正

人が担当する領域

自動修正で解決できないエラーの対応
アーキテクチャレベルの判断
ビジネス要件の最終確認
Issue内容のレビューと優先度付け

この分担により、AIが得意な繰り返し作業は自動化し、人の判断が必要な領域に集中できる体制を実現しました。ポイントは、AIと人の境界を曖昧にしない点。自動で解決できる問題と、人の介入が必要な問題を明確に切り分ければ、どちらも最大限のパフォーマンスを発揮できます。

このシステムで変わる開発状況

観点	As-Is（現状）	To-Be（WorkFlow DevOps導入後）
依頼方法	小さな改善でも要件定義から外注	自然言語で依頼するだけ
テスト	手動テストに時間がかかる	自動テスト・自動修正
変更コスト	プロンプト1行の変更でもコスト発生	すぐに変更・検証が完了
フィードバック	時間がかかる	すぐに結果がわかる
運用者	専門知識を持った人のみ	非エンジニアでも本当に使える

従来のWorkFlow開発では、ちょっとした改善でも要件をまとめて→依頼して→実装を待って→手動でテストして→フィードバックを伝えて...のサイクルを回す必要がありました。このサイクルに時間がかかるため、その間にビジネス要件が変わってしまう場合もあります。

WorkFlow DevOpsでは、このサイクルが短縮されます。実現したい内容を自然言語で伝えるだけで、AIがWorkFlowを作成し、自動でテストし、問題があれば自動で修正。人が介入するのは最初の依頼と最終確認だけです。

この違いは単なる効率化ではありません。試行錯誤のコストが劇的に下がり、とりあえず試してみようが当たり前になります。AIの進化する速度に追従しながら、品質を担保できる。これがWorkFlow DevOpsです。

まとめ

WorkFlow DevOpsは、自然言語からWorkFlowを自動で生成・テスト・修正する開発手法です。

AIエージェントを使った開発は、単にコードを生成するだけではありません。自動で解決できる問題は即座に修正し、人の判断が必要な問題はデータを蓄積し、今後の改善に役立てます。この仕組みによって、AIエージェントと協働した次世代の効率的な開発が実現します。

おわりに

Algomaticでは、こうしたAIネイティブな開発体験を追求しています。

AIでこんな面白い仕組みが作れるのではとアイデアを持っている方
プロンプトエンジニアリングやエージェント設計に興味がある方
AIネイティブなアーキテクチャ設計やシステム設計に興味がある方

一緒に、AIを使った新しい開発パラダイムを作っていきませんか？カジュアル面談やお問い合わせ、お待ちしています。

algomatic.notion.site

2025-12-16

月末の「請求書まだですか？」をゼロに。LLM×Slackで構築した、フリーランスに優しい請求書回収アシスタント

この記事はAlgomaticで開催しているアドベントカレンダー2025の16日目の記事です。

こんにちは。Algomatic でコーポレートエンジニアをしている @raryosu です。

Algomaticは、生成AIを活用したサービス開発を行っているスタートアップです。事業の性質上、多くのプロフェッショナルなパートナー様やフリーランスの方々と協業しており、その数は日々増え続けています。

事業が拡大するのは嬉しいことですが、コーポレート組織の視点では、ある切実な課題が浮き彫りになっていました。それは、「月末月初の、膨大な請求書処理業務」です。

今回は、この泥臭い業務課題を、自社の強みであるLLM（大規模言語モデル）とSlack Botを組み合わせて解決した話をします。

抱えていた課題：お互いに不幸な「手戻り」と「リマインド」

フリーランスの方との取引が増えるにつれ、以下のような課題が深刻化していました。

提出漏れのリマインドコスト「あの人の請求書、まだ来てない…」と管理部が一人ひとりにチャットを送る作業は、心理的にも時間的にも負担です。
記載ミスによる手戻りインボイス登録番号の記載漏れ、宛名の間違い、請求月のズレなど。これらは形式的なミスですが、経理処理上はそのまま受け取ることができません。管理部が目視でチェックし、「ここ直してください」と連絡し、パートナー様が再発行する…。このやり取りは、双方にとって生産性がなく、ストレスフルな時間です。

「パートナー様はサクッと請求書を出して業務に戻りたいし、我々は正しい請求書を期日通りに受け取りたい」このシンプルな願いを叶えるため、LLMを活用した「請求書回収Bot」を内製開発しました。

解決策：Botが「門番」ではなく「アシスタント」になる

今回開発したBotの挙動は以下の通りです。

対象者の自動抽出 Botが契約台帳（データベース）を参照し、「今月有効な契約があるフリーランスの方」を特定します。
稼働確認DMの送付 SlackのDMで「今月の稼働はありましたか？」とBotが聞きに行きます（Push型）。
請求書のアップロード & LLM解析「稼働あり」と答えた方に対し、Botが請求書のPDFアップロードを求めます。ここが肝です。アップロードされたPDFをLLMが解析し、その場でバリデーション（形式チェック）を行います。
社内確認へ形式チェックをパスしたものだけが、各部門管理者や、管理部門へ通知され、最終的な承認・支払処理へと回ります。

こだわりポイント：勝手に「リジェクト」しない

開発にあたり最も意識したのは、「Botが勝手に受領拒否（リジェクト）をしない」という点です。

法的な観点（下請法等）や商習慣から見ても、システムが機械的に「この請求書は受け取りません」と突き返すのはリスクがありますし、何よりパートナー様に対して失礼になりかねません。

そこで、このBotはあくまで「セルフチェックのアシスタント」という立ち位置にしました。

× 機械的な拒否: 「金額が間違っているため、受領できません。」
○ パートナーへの気づき: 「提出ありがとうございます！読み取ったところ、契約金額と請求金額に差分があるようです（交通費などが含まれている場合はそのままで構いません）。このまま提出しますか？それとも修正しますか？」

このように、最終的な提出の意思決定は人間に委ねつつ、ケアレスミスにはその場で気づいてもらう設計にすることで、コンプライアンスとUX（ユーザー体験）の両立を図りました。

技術的な実装の裏側

システム構成としては、Slack API (Bolt) をインターフェースとし、バックエンドで契約DBと Gemini を連携させています。

LLMへのプロンプト戦略：ただのOCRにしないための3つの工夫

請求書の読み取りにおいて最も重要なのは、「文字を認識すること」ではなく「契約内容と合っているか照合すること」です。そのため、単に画像を渡すだけでなく、プロンプトエンジニアリングにおいて以下の3つの工夫を凝らしました。

1. 契約データの動的注入（Context Injection）

LLMに請求書画像だけを渡しても、「金額が正しいか」は判断できません。そこで、プロンプトを生成する直前にデータベースから「そのユーザーの今月有効な契約情報（単価、契約ID、所属組織など）」を引き出し、プロンプト内に動的に埋め込んでいます。

実際のプロンプト生成コード（TypeScript）のイメージです。

// プロンプト内で、DBから取得した契約情報を展開してLLMに渡す
const prompt = `
...
請求書提出者の雇用契約情報：
${validatedContracts.map((c, index) => `
[契約 ${index + 1}]
- 契約ID: ${c.contractId}
- 単価: ${c.unitRate} (${c.unitType})
- 発注部署: ${c.departmentName}
- 会計セグメント: ${c.accountingSegmentName}
`).join('\n\n')}

上記の契約情報を正とし、請求書の明細がこれと一致しているか厳密に判定してください。
...
`;

これにより、LLMは「画像に書かれた数値」と「DB上の正解データ」をその場で突合し、「単価が契約と異なります（契約: 5,000円, 請求: 5,500円）」といった高度なバリデーションを可能にしています。

2. 表記揺れの「名寄せ」正規化

フリーランスの方によって、宛名や部署名の書き方は千差万別です（例：「Algomatic AI Transformation カンパニー」「AX」「Algomatic AX カンパニー」など）。これらを従来のプログラム（正規表現など）ですべて網羅するのは困難ですが、LLMの文脈理解能力を活用することで解決しました。

プロンプト内で以下のような「マッピングルール」を定義し、ゆらぎのある表記をシステム上の正式名称（会計セグメント）に正規化させています。

以下の組織名マッピングルールを参考に適用してください：
- 「Neo Sales」「ネオセールス」「neosales」→ 「ネオセールス」に正規化
- 「Algomatic Works」「アルゴマティックワークス」「AMW」→ 「Algomatic Works」に正規化
- 「AI Transformation」「AX」→ 「AX」に正規化

3. 「NG」と「指摘」の明確な分離

AIが「インボイス番号がないからNG」と機械的に突き返すと、受領拒否等のトラブルになりかねません。そこでプロンプトでは、「数値の不整合などの致命的なエラー」と「宛名ミスなどの軽微な不備」を明確に区別して指示しています。

その他、気になる点があれば詳細にコメントを残してください。
例えば下記のような問題点が考えられますが、該当する場合でもコメントのみに留め、NGとはしないでください
- 請求書の宛先の会社名(大文字小文字等)が間違っている。
- 請求金額の振込先口座名義が漢字で記載されている（カタカナ推奨）。

このように指示することで、Botは「受け取り拒否」ではなく、「宛名が少し違いますが、このまま提出しますか？」といった人間に判断を委ねるアシストが可能になります。

導入後の効果

実際に社内で運用を開始した結果、以下のような変化がありました。

管理部の確認工数が大幅減形式的な不備がBot段階で解消されるため、管理部に届くのは「中身の確認だけでOK」な請求書ばかりになりました。
「うっかりミス」の撲滅インボイス番号の記載漏れなどが激減しました。

パートナー様からの評判「Slackで完結するので楽」「その場でOKが出るので、ちゃんと届いたか不安にならなくて済む」といった声をいただいています。

また、リマインドも人間からではなく Bot から行うので、リマインドをする負荷も、受け取った側の負荷も低くなったのではないかと思います。

おわりに：このシステム、実は…

当初は自社の業務効率化のために作った「ドッグフーディング（自社利用）」プロダクトでしたが、運用してみると想像以上に効果が高く、多くの企業様が抱える「請求書回収の泥臭い課題」を解決できるポテンシャルを感じています。

そこで現在、この「LLM請求書回収アシスタント」を、同様の課題を持つ企業様へ提供（外販）することを検討しています。

フリーランスとの取引が多く、毎月の請求書回収に疲弊している
インボイス制度対応などで、形式チェックの手間が増えている
Slack等のチャットツールで、スマートに業務を完結させたい

もし、このような課題をお持ちの情シス・経理担当者様がいらっしゃいましたら、ぜひ情報交換させてください。まだ製品化前の段階ですが、デモをお見せしたり、運用ノウハウをお話しできると思います。

興味がある方は、X（Twitter）@raryosu または、こちらのフォーム https://algomatic.jp/contact からお気軽にご連絡ください！

明日の記事は、荒井さんの記事です！お楽しみに〜

2025-11-05

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

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

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

取り上げる論文

Inpaint4Drag - ドラッグ操作による画像編集の高速化
V2M4 - 単一動画から4Dアニメーションを生成
LayerAnimate - レイヤー単位で制御可能なAIアニメーション
Web-SSL - 言語ラベルなしの視覚表現学習
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

2025-10-15

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

AI/LLMエージェント

はじめに

こんにちは。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つから構成されます。

Context Retrieval & Generation
Context Processing
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

参考文献

2025-09-22

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

AIコーディング

こんにちは、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つのステップで構成されています。

要求定義（requirements.md）まず「誰が」「何を」「なぜ」求めているのかを明確にします。ステークホルダーの期待値を言語化し、機能要件と非機能要件を整理します。
設計（design.md）アーキテクチャ構成やモジュール設計、データモデルなど、どう設計するかをAIと共に設計していきます。技術選定の根拠も含めて文書化されます。
タスク化（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の実践的な活用

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

レガシーコードのリファクタリング
既存のコードから仕様を逆生成し、改善点を洗い出す
新規機能の追加
既存の仕様に新しい要件を追加し、影響範囲を自動分析
ドキュメントの自動生成
仕様から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の日本語対応と柔軟性が特に印象に残りました。

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

コミュニケーションコストの削減仕様が明文化され、全員が同じドキュメントを参照することで、認識の齟齬が大幅に減少します。特に、AIとの対話を通じて仕様を洗練させていく過程で、曖昧さが自然に排除されていきます。
品質の早期確保要件定義の段階から品質を意識することで、後工程での手戻りが減少します。設計段階でのレビューも仕様に基づいて行われるため、より建設的な議論が可能になります。
ドキュメントの自動生成と保守仕様からドキュメントが自動生成されるため、「コードとドキュメントの乖離」という古典的な問題が解決されます。また、仕様を更新すれば自動的にドキュメントも更新される仕組みは、長期的な保守性を大きく向上させます。
AIとの効果的な協業 SDDツールを使うことで、AIの能力を最大限に活用できます。仕様という明確な指針があることで、AIが生成するコードの品質と一貫性が保たれ、人間とAIの役割分担も明確になります。

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

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

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

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

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

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

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

jobs.algomatic.jp

はじめに

作成した背景と理由

構成・アーキテクチャ

インフラ構成

Claude Agent SDKの採用理由

Bot型エージェントの設計

現時点で実装している機能

リリース結果と動作の紹介

まとめ

この記事のサマリー

前史・基盤技術（2020年）

REALM：検索を事前学習に統合

主要な貢献・技術的特徴

RAGの進化における位置づけ

Dense Passage Retrieval（DPR）：密ベクトル検索の基盤

主要な貢献・技術的特徴

RAGの進化における位置づけ

RAGの誕生（2020年）

RAG原論文：用語と概念の確立

主要な貢献・技術的特徴

RAGの進化における位置づけ

検索拡張の広がり（2022-2023年）

HyDE：仮説的文書による検索改善

主要な貢献・技術的特徴

RAGの進化における位置づけ

FLARE：能動的な前向き検索

主要な貢献・技術的特徴

RAGの進化における位置づけ

Self-RAG：自己反省による品質向上

主要な貢献・技術的特徴

RAGの進化における位置づけ

高度なRAG手法（2024年）

CRAG：検索結果の訂正メカニズム

主要な貢献・技術的特徴

RAGの進化における位置づけ

Adaptive-RAG：クエリに応じた動的戦略

主要な貢献・技術的特徴

RAGの進化における位置づけ

GraphRAG：知識グラフによる構造化検索

主要な貢献・技術的特徴

RAGの進化における位置づけ

Modular RAG：モジュール式の柔軟な組み立て

主要な貢献・技術的特徴

RAGの進化における位置づけ

最新動向（2025-2026年）

Agentic RAG Survey：エージェント型RAGの台頭

主要な貢献・技術的特徴

RAGの進化における位置づけ

Multimodal RAG Survey：テキストを超えた検索拡張

主要な貢献・技術的特徴

RAGの進化における位置づけ

Context Engineering Survey：より広い枠組みへの位置づけ

主要な貢献・技術的特徴

RAGの進化における位置づけ

まとめ：RAGの進化とこれから

RAGの進化の軌跡

今後の展望

一緒に働きませんか？

はじめに：ノーコードツールの限界

社内の取り組み

仕組み

各エージェントの役割

品質を担保する3つの自動化

WorkFlow DevOpsの特徴

LLMによる自動テスト・自動判定

2つの改善サイクル

高速な仮説検証

Issueを活用したコンテキストエンジニアリング

AIと人の分担アーキテクチャ

このシステムで変わる開発状況

まとめ

おわりに

抱えていた課題：お互いに不幸な「手戻り」と「リマインド」

解決策：Botが「門番」ではなく「アシスタント」になる

こだわりポイント：勝手に「リジェクト」しない

技術的な実装の裏側

LLMへのプロンプト戦略：ただのOCRにしないための3つの工夫

1. 契約データの動的注入（Context Injection）

2. 表記揺れの「名寄せ」正規化

3. 「NG」と「指摘」の明確な分離