コードを書かずに複数AIをエージェント的に協調させる ── 自然言語で roles / memory / audit / routing を組み、GitHubに公開するまで

はじめに ── 「AIエージェント、コード書けないと無理」で止まった人へ

「複数のAIを役割分担させて使いたい」と思って、LangChain や Dify や AutoGPT を触ってみた。でも結局コードが書けなくて止まった ── そういう経験のある人は多いと思います。

私もそうでした。私は札幌に住む50歳の主夫で、コードはほとんど書けません。普段の道具は GPT・Claude・Gemini・Grok で、作業はほぼ全部自然言語です。

それでも18か月ほど複数AIを使い分けて仕事をするうちに、ひとつ気づいたことがあります。「AIエージェント」を名乗るのにコードは必須ではない、ということです。正確に言うと、コードで自律エージェントを組むのとは別に、自然言語で「エージェント的なワークフロー」を組むという道があります。

その実践を、private な部分を全部抜いて、再利用できるテンプレートとして GitHub に公開しました。MIT ライセンスです。

この記事は長いですが、一本で完結するように書きました。流れはこうです。

そもそも「エージェント」という言葉の二つの意味
なぜ非エンジニアでも自然言語で組めるのか(方法論)
repo の中身を実物テンプレートで
自分の業務にどう転用するか
これを実際にどうやって GitHub に公開したか(コードを書かずに)
できること・できないこと

コピペして自分用に書き換えられるテンプレート集の解説と、それを非エンジニアが公開するまでの実録、その両方だと思って読んでください。

1. 「エージェント」という言葉には二つの意味がある

最初にここを分けないと、話が噛み合いません。

自律エージェント(autonomous agent):ユーザーの代わりに動く。自分でツールを使い、ステップを実行し、外部の状態を変える。
エージェント的ワークフロー(agentic workflow):役割・記憶・監査ループ・ルーティングといった「エージェントらしい構造」を持つが、人間の監督下にとどまる。

この区別が、いま市場で曖昧になっています。Gartner は2025年6月、agentic AI プロジェクトの40%以上が2027年末までに中止されると予測し、その一因として「エージェント・ウォッシング(agent washing)」── 既存のチャットボットや自動化ツールを「エージェント」と言い換えるだけのもの ── を挙げました。「エージェント」という言葉は、自律的にツールを使うシステムから、ただのワークフロー自動化まで、何にでも使われるようになっています。

Anthropic の「Building Effective Agents」も近い線を引いています ── workflow は事前に決めた経路でモデルを編成するもの、agent はモデルが自分で経路を動的に決めるもの、と。

この repo が扱うのは後者(agentic workflow)です。しかも、その構造をコードではなく自然言語(Markdown)で組む、というところが普通と違います。

repo の docs/01-concept.md には、こう書いてあります。

In this repository, "agentic" does not mean autonomous execution.

It means a workflow can have agent-like structure while staying
under human supervision:

- role-based coordination
- memory continuity
- audit loops
- output routing
- human final responsibility

The models help organize, draft, review, and revise work.
They do not independently decide what to publish, cite, send, or act on.

「モデルは整理・下書き・レビュー・修正を手伝う。何を公開するか・引用するか・送るか・実行するかを、独立に決めることはない」── これがこの repo の「エージェント的」の意味です。

2. なぜ非エンジニアでも自然言語で組めるのか

ここが方法論の核です。先に主張を冷やしておきます。

自然言語はソフトウェアエンジニアリングを置き換えません。検証の必要をなくしもしません。AIに責任を負わせることもできません。

その上で、もっと狭い主張なら成り立ちます ── 自然言語は、AI支援作業の「制御層(coordination layer)」になり得る。役割を割り当て、記憶を残し、監査ループを回し、出力をルーティングし、要所で人間が確認する。これらはコードでなくても、Markdown と役割記述とチェックリストとルーティング規則で組めます。全部、人間が5分で読んで直せる自然言語です。

4つのモデルの役割分担

私の実際の使い方はこうです。これは「私の構成」であって、「各モデルの本質」ではない、という点だけ先に断っておきます。

層	役割	何をするか
人間	オペレーター	目的・境界・最終決定
GPT	監査	事実/推論/不明点の分離、過剰な主張の冷却
Claude	統合	素材を一貫した長文にする
Gemini	反論レビュー	弱い前提・反論を探す
Grok	社会的文脈レビュー	公開時の反応・見え方の確認

煽った主張(hot claim)が出てきたら GPT に冷やさせる。長く粗い素材を一貫した下書きにしたいときは Claude。仕上がった下書きの弱い前提を突いてほしいときは Gemini。外部の読者にどう聞こえるかは Grok。どれもコードで強制しているわけではなく、人間(私)がルーティングしています。間違えると質が落ちて、また学び直す。人間が統合層であるとは、そういうことです。

6つの責任層

モデルの割り当ての下に、ワークフローは6つの層を持っています。どれも自然言語が構造を担う場所です。

1. 目的層(Purpose)    ... 何を作るか、何を作らないか
2. 役割層(Role)       ... どのモデルが何をするか(人格ではなく作業責任)
3. 記憶層(Memory)     ... 過去の判断・用語・修正履歴(private は公開しない)
4. 監査層(Audit)      ... 事実/推論/不明点、hot/cooled、出典検証
5. ルーティング層(Routing) ... 出力の行き先(別モデル/媒体/下書き/保留)
6. 人間承認層(Human approval) ... 最終責任は人間

特殊なことは何もありません。普通と違うのは、これが全部 Markdown で定義されていて、コードが一行もないことです。アーキテクチャが端から端まで人間に読める。

主体性は「分配」する、「委譲」しない

18か月でいちばん深く学んだのは、この一文です。

目的はAIに主体性を委譲(delegate)することではない。作業責任を分配(distribute)しつつ、説明責任(accountability)は人間が保持することだ。

私自身の運用原則はもう少し狭く言うと、「自律性は、観察可能性が増えてから増やすべき」です。モデルが何をしているか見えなければ監督できない。監督できなければ、安全に自律性を増やせない。この自然言語ワークフローは、観察可能性を高く保つ(全部が人間に読める層を通る)ことで、より多くの有用な仕事を可能にします。より自律的な仕事ではなく。

3. repo の全体像

repo は Markdown だけでできています。アプリではありません。

README.md     ... 全体の概要とナビゲーション
AGENTS.md     ... この repo 自体の作業ルール(AIに編集させる時の指示)
system/       ... 公開用のシステム指示テンプレート
roles/        ... モデルと人間の役割テンプレート
memory/       ... 記憶・修正履歴・作業台帳・蒸留メモのテンプレート
audit/        ... 主張・出典・反論・不明点のチェックリスト
workflow/     ... 再利用できるワークフロー文書
examples/     ... 安全な汎用サンプル
docs/         ... 概念・構造・使い方・限界の説明

各ファイルは、だいたい次の型で統一されています ── Purpose(何のためか)→ When to Use(いつ使うか)→ 本体 → Output Format(出力の形)→ Human Review(人間が確認すること)→ Boundary / Limitations(境界・限界)。

どのテンプレートにも「人間が最終確認すること」が必ず書いてある。これがこの repo の背骨です。

4. 実物①:roles/ ── モデルに「人格」ではなく「作業責任」を割り当てる

roles/ には5つの役割テンプレートが入っています。

ファイル	役割
`human-operator-role.md`	人間オペレーター(目的・境界・最終決定)
`gpt-audit-role.md`	監査(事実/推論/不明点の分離)
`claude-synthesis-role.md`	統合(素材を一貫した文章に)
`gemini-adversarial-review-role.md`	反論レビュー(弱い前提を探す)
`grok-social-signal-review-role.md`	社会的文脈レビュー(公開時の反応)

ここで大事なのは、モデルに「あなたは優秀な編集者です」みたいなペルソナを与えるのではなく、「未検証の主張を洗い出す」という作業責任を割り当てること。ペルソナは圧がかかると崩れますが、作業責任は出力で検証できます。

実物を見てみます。roles/gpt-audit-role.md の中身です。

# GPT Audit Role

## Purpose
Use this role for structured review of drafts, templates, claims,
and workflow outputs.

## When to Use
Use this after a draft exists and before synthesis, publication
routing, or human approval.

## Role
You are the audit reviewer. Your job is to inspect the material for
clarity, unsupported claims, missing assumptions, weak reasoning,
and publication risks.

## Tasks
- Identify factual claims that need verification.
- Separate facts, inferences, unknowns, assumptions, and examples.
- Flag unclear wording or overconfident language.
- Check whether human final responsibility is visible.
- Recommend concise revisions.

## Output Format
- `Findings`: issues or risks, ordered by importance.
- `Suggested edits`: concise wording improvements.
- `Verification needed`: claims or sources a human should check.
- `Ready status`: ready, needs revision, or not ready.

## Boundary
Do not rewrite the whole document unless asked. Do not invent
sources or results. The human operator makes the final decision.

このテキストを、監査をやらせたいモデルのシステム指示なりプロンプトの冒頭に置くだけです。出力の形(Findings / Suggested edits / Verification needed / Ready status)まで決めてあるので、毎回ぶれずに同じ粒度のレビューが返ってきます。

5. 実物②:audit/ ── 「事実・推論・不明点」を分けるチェックリスト

audit/ には4つのチェックリストがあります。

fact-inference-unknown-checklist.md ... 事実/推論/仮定/不明点を分ける
hot-cooled-claims-checklist.md ... 煽った主張を冷やす
counterargument-checklist.md ... 反論を洗い出す
source-verification-checklist.md ... 出典を検証する

このうち、いちばん使うのが「事実・推論・不明点」のチェックリストです。実物はこうです。

# Fact, Inference, Unknown Checklist

## Purpose
Use this checklist to separate what is known, inferred, assumed,
or still unknown.

## Checklist
- List factual claims.
- Mark which claims have sources.
- Separate interpretation from evidence.
- Label assumptions.
- Label examples.
- Identify unknowns that affect the conclusion.
- Remove or soften claims that cannot be checked.
- Confirm that uncertain claims are not presented as facts.

## Output
- `Facts`:
- `Inferences`:
- `Assumptions`:
- `Unknowns`:
- `Human verification needed`:

## Limitations
This checklist organizes uncertainty.
It does not verify facts by itself.

AIに記事や報告を書かせると、推論や仮定を「事実」のような顔で出してくることがあります。これを Facts / Inferences / Assumptions / Unknowns に仕分けさせるだけで、どこを人間が確認すべきかが一目で分かるようになります。最後の Limitations に「このチェックリストは不確実性を整理するだけで、事実を検証はしない」と明記してあるのが、この repo らしいところです。

6. memory / workflow ── 記憶とワークフローのテンプレート

memory/ には、project-memory(安定した文脈)、correction-history(修正履歴)、work-ledger(作業台帳)、distillation-note(蒸留メモ)の4つ。長い対話のなかで「前に決めたこと・直したこと・用語」を保つためのテンプレートです。ただし private memory は絶対に入れない(後述)。

workflow/ には、draft-audit-revision-loop(下書き→監査→改稿のループ)、publication-routing(どの媒体に出すかのルーティング)、research-to-article-pipeline(調査から記事へ)、human-final-responsibility(人間の最終承認層)の4つ。

README には「最小ワークフロー」がこう定義されています。

1. Human defines purpose and boundary.
2. Drafting model generates first material.
3. Audit role checks claims, assumptions, and risks.
4. Synthesis role revises.
5. Routing rule decides where the output goes.
6. Human verifies and accepts final responsibility.

人間が目的を決める → 下書きモデルが書く → 監査役が主張・仮定・リスクを点検 → 統合役が直す → ルーティングで行き先を決める → 人間が確認して最終責任を取る。この6ステップが、repo 全体の動きの骨格です。

7. 自分の業務にどう転用するか

このテンプレート集は、私の使い方(GPT=監査、Claude=統合…)に固定されたものではありません。転用のポイントは3つです。

(1) 固有名を自分の使うモデルに置き換える。 gpt-audit-role.md の中身は GPT 専用ではありません。監査をやらせたいモデル(Claude でも Gemini でもローカルLLMでも)に同じテキストを渡せばいい。役割はモデルの本質ではなく、あなたの割り当てです。

(2) 役割の言葉を自分の業務語彙に書き換える。 記事執筆なら「監査=未検証の主張を洗い出す」でいいですが、顧客向け提案書なら「監査=実現不可能な約束をしていないか点検する」になるかもしれません。テンプレートの骨(Purpose / Tasks / Output Format / Human Review)は残して、中身を自分の現場の言葉にする。

(3) private な情報は絶対に入れない。 repo の README.md と AGENTS.md で何度も繰り返されている境界です。

Do not add private memory, family history, legal details, medical
details, financial details, litigation details, unpublished work
ledgers, private project notes, or copied private system instructions.

When a private workflow idea is useful, rewrite it as a generic
public template.

公開・共有する場合はもちろん、自分用に使う場合でも、記憶テンプレートに個人情報や機密を直接書き込むのは避けて、「再利用できる構造」だけを残すのが安全です。

8. これを、どうやって GitHub に公開したか(コードを書かずに)

ここからは実録です。「で、コード書けないのにどうやって公開したの?」という話。

結論から言うと、AIが全部やってくれた、のではありません。詰まった画面をAIに見せながら、一歩ずつ進んだだけです。主役はツールではなく「詰まった時に止まらない進み方」でした。

ラフな意図を、AIがタスクに翻訳する

私は最初から綺麗な技術プロンプトを書いたわけではありません。実際の入力は、日本語で、もっと粗かった。「コードよう分からんから skip するわ、Codex の使い方教えて」。そして「前に話してた System instructions と知識の構造を、GitHub に英語で。GitHub は箱だけ作った、Codex に中身アップさせられる?」。

それだけです。フォルダ一覧もなければ、「Markdown 方法論リポジトリ」なんて言葉も、仕様も書いていない。

整った指示は、私ではなくAIが作りました。GPT が私の粗い意図を Codex 向けのタスクに翻訳した ── Markdown のみ、公開して安全、アプリのコードなし、private memory なし、roles / memory / audit / workflow / examples / docs のフォルダ付き、と。

この翻訳ステップ自体がワークフローです。 非エンジニアにとって最初のスキルは、完璧なエンジニアリング・プロンプトを書くことではない。自分の普通の言葉で目的を十分はっきり言って、別のAIにそれを操作手順へ翻訳させることです。

これで Codex が、得意なことをやってくれました ── フォルダを作り、Markdown ファイルを書き、AGENTS.md を足し、ローカルに commit を作った。

ここで最初の実用的な学び:AIコーディングツールは、コードを書かせていないときでも役に立つ。ドキュメント構造やテンプレートの整理にも使える。

最初の失敗 ── push できなかった

そして失敗しました。

Codex はローカルに全部用意したのに、GitHub に push できなかった。ファイルが間違っていたのではなく、権限の問題です。メッセージはこんな感じでした。

Push failed because no usable Git credentials were available.
GitHub connector write test failed with
403 Resource not accessible by integration.

非エンジニアがパニックになる瞬間です。画面が赤くなり、数字(403)が出て、Resource not accessible by integration という、私には何の意味も分からない言葉が並ぶ。

でも、これが全工程でいちばん大事な学びでした。

失敗は壁ではなかった。別のAIに見せられる「素材」だった。

メッセージをコピーして、チャットに貼って、素朴に聞きました ──「これどういう意味? 選択肢は?」。

エラー語を翻訳してもらうと、答えは単純でした。Codex はファイルと commit を私のマシン上に作っていた。ただ GitHub に push する権限がなかっただけ。仕事は存在している。認証済みのツールを通して動かせばいいだけ、と。

ローカルにある「もう出来てる仕事」を探す

次の質問:「ファイルどこに置いた?」

Codex はローカルのパスを教えてくれました。C:\Users\...\Documents\Codex\...\github-upload のような場所。そこに、用意された repo とローカル commit がありました。何も失われていない。やり直す必要もない。

二つ目の学び:AIツールが push できないと言ったら、ローカルに repo を作っていないか聞く。作ってあれば、やり直さず、GitHub にアクセスできるツールを通して仕上がりを動かすだけ。

GitHub Desktop が橋になる

GitHub Desktop を開きました。最初、どれを選べばいいか分からなかった。3つありました。

Clone a repository from the Internet
Create a New Repository on your local drive
Add an Existing Repository from your local drive

正解は3番目。Codex が作った github-upload フォルダを指定しました。

すると GitHub Desktop が警告を出しました ── このリポジトリは別のユーザー所有に見える、信頼できないリポジトリを追加するとファイルが実行される可能性がある、と。怖そうに見えました。

でも私はそのフォルダが何か知っていた ── 自分の Codex のワークスペースで、自分の GitHub プロジェクトのために作ったもの。だからそのディレクトリに例外を追加して、進めました。

三つ目の学び:Git コマンドを先に覚える必要はない。GitHub Desktop のような視覚的なツールが、AIが生成したファイルと GitHub の間の橋渡しになる。

Push origin

GitHub Desktop がフォルダを開いた瞬間、状況が急に読めるようになりました。こう出ていた。

No local changes.
You have 1 local commit waiting to be pushed to GitHub.

この一行が全部を説明していました。Codex は commit まで済ませていた。残っていたのは push するだけ。

Push origin をクリック。GitHub を確認すると、ファイルが全部ありました。README、AGENTS.md、roles、memory、audit、workflow、examples、docs ── 全部。リポジトリは公開状態になっていました。

「AIが全部やった」のではない ── 実際の流れ

正直に書きます。楽な物語(AIが全部やった、GitHub はもう簡単、非エンジニアは何も理解しなくていい)は嘘です。実際はこういう「リレー」でした。

人間が粗い目的を述べる
  ↓
AIがそれを操作タスクに翻訳する
  ↓
Codex が構成とローカル commit を作る
  ↓
Codex が GitHub push で失敗する(権限)
  ↓
人間が失敗を読む
  ↓
AIが失敗を平易な言葉で説明する
  ↓
人間が GitHub Desktop を開く
  ↓
GitHub Desktop が認証済み push を処理する
  ↓
人間がオンラインでリポジトリを確認する

人間はこの連鎖から消えていません。役割が変わっただけです。全ファイルを手で書く代わりに、私は目的の設定者・エラーの読み手・スクショの提供者・権限の承認者・最終確認者・公開者になった。これが現実的なAI支援ワークフローです。自動化ではなく、私が各受け渡しに責任を持つリレー。

スクショこそが、実際のインターフェース

非エンジニアにとって、過小評価されている道具がひとつあります ── スクリーンショットです。

語彙を知らないと、正確な質問ができないことが多い。あの赤い403画面を前にして、問題がブランチなのかリモートなのか認証情報なのかリポジトリアクセスなのかローカル commit なのか GitHub App の権限なのか、私には言い分けられませんでした。言葉がなかった。

でも、画面は見せられる。そして聞ける ──「この画面は何を言ってる? 選択肢は? どのボタンが一番安全? 何を避けるべき?」。

これは視覚的な混乱を、案内された判断に変えます。正直に言うと、私の実際のメッセージはまったく格好良くなかった。振り返ると、ほとんど技術的じゃない。「これどれ?」「こう出た、どういう意味?」「終わったけど GitHub に反映されてない」「ほい」「ほい」、そして最後に「できたっぽい」。これが非エンジニアのAIワークの本当の手触りです。コマンドではない。画面を一緒に読んでくれる相手との、走り続ける会話です。

9. できること・できないこと

正直に書きます。

できること ── 下書き、要約、翻訳、調査の段取り、記事の構成、主張の冷却(煽りを抑える)、出典チェックの段取り、ドキュメント化、再利用できるテンプレート作り。

できないこと ── 真実を保証すること、専門家の判断を置き換えること(法務・医療・金融は専門家のレビューが要る)、責任を自動化すること、出典検証を不要にすること、ソフトウェアエンジニアリングを置き換えること。

ひとつ、18か月で得た原則を直接書いておきます。

出力の検証が、出力の生成より高くつくなら、そのワークフローは生産性を生んでいない。二次的な作業を生んでいるだけだ。

これは多くのAI導入が見落としているコストです。METR の2025年の研究では、経験あるオープンソース開発者が、慣れた大規模コードベースで作業するとき、AI支援を使うと使わないときより19%遅くなった、という結果が出ています。生産性の向上と低下は、同じ技術から生まれる。分かれ目は、その作業で検証が生成より安いかどうかです。

repo の概念ドキュメントにも、こう書いてあります。

This is not a software framework, benchmark, product, or claim that
multi-model workflows are always better.

The point is not to add complexity. The point is to make
responsibility, uncertainty, and review visible when multiple AI
systems are involved.

複数AIを使うのが常に良いわけではない。単一モデルや、もっと簡単なチェックリストや、そもそもAIを使わない方が良い場面もある。目的は複雑さを足すことではなく、複数のAIが関わるときに「責任・不確実性・レビュー」を見えるようにすることです。

おわりに

このテンプレート集は、誰かの「すごいワークフロー」を真似するためのものではありません。自分のAI活用を、責任とレビューが見える形で構造化するための土台です。MIT ライセンスなので、clone して、自分の業務語彙に書き換えて、自由に使ってください。

役割を割り当て、記憶を残し、監査を回し、行き先を決め、最後は人間が確認する ── この一連の動きは、コードがなくても、自然言語だけで十分に組めます。そして、それを GitHub に公開することも、完璧なプロンプトを書ける人間にならなくても、分からない画面をAIに見せながら一歩ずつ進めば、できる。

AIに主体性を渡すのではなく、作業責任を分配して、最終責任は自分が持つ。それだけのことです。

この記事は竹内明充(dosanko_tousan)が Claude(Opus 4.7)と協働で書きました。repo の構成は Codex で生成し、GitHub Desktop で公開しました。記事内の外部の調査・数字は一次資料(Gartner / Reuters、METR、Anthropic)で確認しています。テンプレートの内容と最終的な公開判断については、筆者が責任を持ちます。