自然言語だけで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

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

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

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

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

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

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

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

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

1. 提出漏れのリマインドコスト 「あの人の請求書、まだ来てない…」と管理部が一人ひとりにチャットを送る作業は、心理的にも時間的にも負担です。

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

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

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

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

1. 対象者の自動抽出 Botが契約台帳（データベース）を参照し、「今月有効な契約があるフリーランスの方」を特定します。

2. 稼働確認DMの送付 SlackのDMで「今月の稼働はありましたか？」とBotが聞きに行きます（Push型）。

3. 請求書のアップロード & LLM解析 「稼働あり」と答えた方に対し、Botが請求書のPDFアップロードを求めます。 ここが肝です。 アップロードされたPDFをLLMが解析し、その場でバリデーション（形式チェック）を行います。

4. 社内確認へ 形式チェックをパスしたものだけが、各部門管理者や、管理部門へ通知され、最終的な承認・支払処理へと回ります。

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

開発にあたり最も意識したのは、「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 からお気軽にご連絡ください！

---

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

コンピュータビジョンの最前線 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運用などビジネス用途での活用も見込まれます。

参考リンク

• 論文 (arXiv)
• プロジェクトページ

---

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

概要

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

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

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

技術的アプローチ

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

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

応用例

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

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

参考リンク

• 論文 (arXiv)
• プロジェクトページ

---

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

概要

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

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

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

技術的アプローチ

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

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

応用例

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

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

参考リンク

• 論文 (arXiv)
• プロジェクトページ

---

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同等以上の性能が出ています。

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

参考リンク

• 論文 (arXiv)
• プロジェクトページ

---

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

参考リンク

• 論文 (arXiv)
• GitHub

---

まとめ

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

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

機能比較表

機能	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 エンドポイントを介して応答することで、セッションを途切れさせずに継続できるように設計しています。

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

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

• 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