1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

開発中のAIエージェントのハーネスフレームワークで使っている圏論の考えをまとめた

1
Posted at

『Compositional Software Design for Agentic Systems』の概要

AI エージェントに実装やテストを書かせること自体は、もう珍しくなくなってきました。
ただ、実務で本当に難しいのは「ちゃんと速くなる」ことよりも、「どこまで任せてよくて、誰が最後に責任を持つのか」を説明できる状態を保つことだと思っています。

これまで、日本語で『圏論によるAIエージェント時代の合成的ソフトウェア設計』を書いて、仕様・設計・検証をどうつなぐかを整理してきました。
並行して、その考えを実際の開発フローに落とすために ae-framework も開発しています。

その流れで今回、AI エージェント利用にフォーカスした、Compositional Software Design for Agentic Systems を書きました。この記事では、内容を軽く紹介します。

ここまで開発の流れ

ざっくりいうと、流れはこんな感じです。

  1. 日本語で、AI エージェント時代の設計成果物をどう作るかを圏論ベースで整理した。
  2. その考えを CI / policy gate / evidence / Context Pack として運用に載せるために ae-framework を作っている。
  3. そのうえで、AI エージェントとの責任分界に寄せて、まとまった説明を書いた。

なので、今回は「日本語版の単純翻訳」というより、
AI支援開発をどう統治するかにフォーカスし直したもの、という位置づけです。

これは何の本か

副題は、

A Category-Theoretic Guide to Human-AI Boundaries and Verifiable Engineering

です。

タイトルだけ見ると少し硬そうですが、やりたいことはかなり実務寄りです。

この本が扱っているのは、たとえば次のような話です。

  • AI が変更案を出したとして、そのまま実行してよいのか
  • 人間の承認はどこに置くべきか
  • レビュー時に何を証跡として残すべきか
  • 後から「なぜこの変更が通ったのか」を説明できるか

つまり、AI をどう賢く使うかというより、
AI が入っても壊れにくい開発フローをどう設計するかの本です。

個人的にこの本でやりたかったこと

AI を使った開発の話は、どうしても「どのモデルが強いか」「どのプロンプトが効くか」に寄りがちです。

もちろんそれ自体は大事なのですが、実務で長く効くのはそこだけではありません。
むしろ重要なのは、

  • 何を固定して AI に渡すのか
  • どこに境界を引くのか
  • どの成果物をレビュー対象にするのか
  • 実行前後の証跡をどう残すのか

だと考えています。

この本では、そのための言葉として圏論を使っています。
ただし、数学のための数学ではなく、設計レビューのための語彙として使っています。

たとえば、

  • object = 安定した成果物や状態
  • morphism = 意味のある変換
  • composition = 変換のつながり
  • diagram = 複数の経路で意味が保たれているかの確認
  • effect boundary = 外部状態を書き換える境界

という感じです。

どんな内容なのか

本全体は大きく 3 部構成です。

Part I: Foundations and Responsibility Boundaries

まずは、人間と AI の責任境界をどう切るか。
ここで「誰が提案して、誰が承認するのか」を明確にします。

Part II: Structure-Preserving Translation and Integration

次に、仕様・設計・実装・レビューのあいだで、
どうやって意味を壊さずに写していくかを扱います。

Part III: Coordination, Effects, and Delivery

最後に、オーケストレーションや副作用、実行境界まで降ろします。
AI エージェントがツールを叩く、CI が動く、承認後にデプロイされる、といった話はこのあたりです。

最小例がわかりやすい

この本では、かなり小さな例を何度も使います。

Change Request -> Review Plan -> Approved Change

AI が Review Plan を作ることはできる。
でも Approved Change にする責任は人間側に残す。

この分け方が本書のかなり大事なポイントです。

「AI が提案すること」と「人間が承認すること」を分離すると、

  • 権限の境界が見える
  • レビュー観点が作りやすい
  • どこで証跡を残すべきか整理しやすい
  • 後から監査しやすい

というメリットがあります。

日本語版や ae-framework との関係

この英語本だけを単体で読んでもよいのですが、
自分の中では次のようにつながっています。

  • 日本語版
    設計成果物、Context Pack、GitHub/CI まで含めて、日本語で実務に寄せて整理したもの
  • ae-framework
    それを実際の開発フローに載せるためのハーネス / assurance control plane
  • 今回の英語本
    その考えを、Human-AI BoundariesVerifiable Engineering に絞って英語で通したもの

なので、英語版は「前の本の焼き直し」ではなく、
圏論を AI エージェント利用にどう効かせるかを、英語圏向けに整理し直した本だと思ってもらえると近いです。

どんな人に向いているか

特に合うのは、たぶんこんな人です。

  • AI を開発フローに入れたいけれど、責任分界を曖昧にしたくない人
  • 仕様・設計・検証・CI をバラバラではなく、ひとつの流れとして扱いたい人
  • プロンプト最適化よりも、レビュー可能性や監査可能性を重視したい人
  • Staff Engineer / Tech Lead / Platform Engineer 的な立場で設計を見ている人

逆に、

  • まずはプロンプト集がほしい
  • モデル比較をたくさん見たい
  • 圏論を純粋数学として深く学びたい

という期待とは少し違うと思います。

どこから読むのがおすすめか

最初に読むなら、この順番が入りやすいです。

  1. Introduction
  2. Chapter 01: Human and AI Responsibility Boundaries
  3. Minimal Example
  4. Chapter 03: Diagrams and Commutativity
  5. Chapter 09: Effect Boundaries
  6. Chapter 10: From Specification to AI-Assisted Implementation

まず最小例を見ると、この本が何をしたいのかがかなり掴みやすいです。

まとめ

『Compositional Software Design for Agentic Systems』は、
AI エージェント時代の開発を「自動化の話」としてではなく、

  • 誰が責任を持つのか
  • どの成果物をレビューするのか
  • どの境界で承認が必要なのか
  • どの証跡を残すのか

まで含めた設計の話として扱っています。

AI に実装を任せること自体は、これからもっと普通になると思います。
そのときに必要になるのは、「速い」だけではなく、ちゃんと説明できることです。

そのための共通言語として、圏論をソフトウェア設計に持ち込む。
これは、そういう立場でまとめました。

興味があれば、まず Overview と Introduction だけでも見てもらえると雰囲気は伝わると思います。

Links

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?