さかした
AIの進化が止まらない。「Loop Engineering」「Graph Engineering」という言葉を聞いたことがありますか？
2026年08月12日
見出しはありません
要約を生成中...
みなさんは、
「Loop Engineering（ループエンジニアリング）」
「Graph Engineering（グラフエンジニアリング）」
という言葉を聞いたことがありますか？
自分も最近、AIを使った開発を続ける中で知った言葉です。
調べたり、実際にAIを使って開発したりしていると、
AI開発は、また次の段階に進もうとしているんだな
と感じます。
少し前まで、AI活用というと、
「どういうプロンプトを書けば、良い回答が返ってくるか」
という Prompt Engineering（プロンプトエンジニアリング） が大きなテーマでした。
そこから、
「AIにどんな情報を渡せば、より正しく判断できるか」
という Context Engineering（コンテキストエンジニアリング） が重要になってきました。
そして現在はさらに、
「AIにどのような仕事の進め方をさせるのか」
というところまで考えるようになってきています。
その一つが、
Loop Engineering（ループエンジニアリング）
です。
例えばAIに、
「この機能を実装してください」
とお願いしたとします。
AIがコードを書いて、
「実装しました」
で終わる。
これが一番シンプルなAIの使い方です。
でも、実際の開発はそれだけでは終わりません。
実装
↓
テスト
↓
レビュー
↓
問題を発見
↓
修正
↓
再テスト
↓
再レビュー
問題があれば修正し、もう一度確認する。
人間が行っている開発も、このような繰り返しで進んでいます。
それならAIにも、この繰り返しをしてもらえばいい。
これが、Loop Engineeringを理解するときの分かりやすいイメージです。
ここで大切なのは、単純にAIへ、
「問題がなくなるまで直してください」
とお願いすることではありません。
例えば、あらかじめ次のような終了条件を決めておきます。
テストがすべて通っている
lintエラーがない
型エラーがない
API仕様との不整合がない
セキュリティ上の重大な問題がない
既存実装との不要な重複がない
そして、
実装
↓
検証
↓
終了条件を満たしている？
├─ NO → 修正 → 再検証
└─ YES → 完了
という流れを作ります。
AIに、
「なんとなく良くなるまで頑張って」
とお願いするのではなく、
「何をもって完成とするのか」
を人間側が定義するわけです。
自分は、この考え方がとても重要だと思っています。
会社などでよく使われる考え方に、PDCAがあります。
Plan
↓
Do
↓
Check
↓
Action
↓
Planへ戻る
Loop Engineeringも考え方としては少し似ています。
実行
↓
評価
↓
問題発見
↓
改善
↓
もう一度実行
AIに一回だけ答えを出してもらうのではなく、
実行 → 評価 → 改善
を繰り返してもらう。
AIがコードを書けるようになったからこそ、このような使い方ができるようになってきました。
そして、その先にGraph Engineeringがある
Loop Engineeringだけでも、かなり強力です。
でも、開発が複雑になってくると、一つ疑問が出てきます。
「全部を一つのAIにやらせる必要があるのか？」
ということです。
例えば、
実装担当AI
↓
テスト担当AI
↓
レビュー担当AI
↓
判定
├─ 問題あり → 実装担当AIへ戻る
└─ 問題なし → 完了
というように、AIごとに役割を分けることもできます。
さらに、
実装AI
↓
├─ セキュリティレビューAI
├─ コード品質レビューAI
└─ テストAI
↓
結果を統合
↓
問題あり？
├─ YES → 実装AIへ戻る
└─ NO
↓
人間が最終確認
↓
完了
というような構造も考えられます。
このように、
AI・ツール・ルール・人間などを組み合わせて、仕事の流れそのものを設計する
という考え方が、最近「Graph Engineering」という言葉で語られ始めています。
LoopとGraphは何が違う？
自分は、次のように理解しています。
AIに「実行 → 評価 → 改善」を繰り返してもらう。
実装
↓
テスト
↓
失敗
↓
修正
↓
再テスト
↓
成功
ポイントは、
「どう繰り返すか」
を設計することです。
Graph Engineeringでは、さらに仕事全体を考えます。
例えば、
誰が担当するのか
どの順番で実行するのか
どの条件で次へ進むのか
どの条件で前へ戻るのか
どの処理を並列で実行するのか
どこで人間が確認するのか
といったことを設計します。
つまり、自分なりに簡単に表現すると、
Loop Engineering = AIの「繰り返し」を設計する
Graph Engineering = AIを含めた「仕事全体の流れ」を設計する
という違いです。
AI開発の進化を並べてみると面白い
ここまでを並べてみると、AIの使い方が少しずつ変わってきていることが分かります。
AIに「何をお願いするか」を考える。
人間
↓
良い指示を書く
↓
AI
↓
回答
例えば、
どんな指示を書くか
どんな質問をするか
どんな形式で回答してもらうか
を考えます。
AIに「何を知ってもらうか」を考える。
ルール
仕様
既存コード
ドキュメント
過去の情報
↓
AI
↓
判断・実装
AIへの指示だけではなく、
AIが判断するために必要な情報そのものを整える
という考え方です。
AIに「どう改善を繰り返してもらうか」を考える。
AIが実行
↓
評価
↓
問題あり？
├─ YES → AIが修正 → 再評価
└─ NO → 完了
一回の回答で終わらせず、一定の条件を満たすまで改善してもらいます。
AIたちに「どう仕事をしてもらうか」を考える。
┌→ AI A
人間 → タスク分解 ──┼→ AI B
└→ AI C
↓
評価
↓
┌──────────────┐
↓ ↓
再実行 人間確認
↓ ↓
AI 完了
役割、順番、分岐、並列処理、評価、人間の承認などを含めて、
仕事全体の構造を設計する
という考え方です。
4つを一言でまとめると
Prompt Engineering
↓
AIに「何を指示するか」
Context Engineering
↓
AIに「何を知ってもらうか」
Loop Engineering
↓
AIに「どう改善を繰り返してもらうか」
Graph Engineering
↓
AIたちに「どう仕事をしてもらうか」
さらに短くすると、
指示する
↓
情報を与える
↓
繰り返させる
↓
仕事の流れを設計する
AI活用が、
「AIへのお願いの仕方」
から、
「AIが働く仕組みそのものを設計する」
方向へ進んでいるように感じます。
これ、会社の仕事にも少し似ていませんか？
Graph Engineeringについて調べていて、自分は会社組織にも少し似ていると感じました。
会社でも、一人の優秀な人にすべての仕事を任せるわけではありません。
例えばソフトウェア開発なら、
企画
↓
設計
↓
開発
↓
コードレビュー
↓
テスト
↓
品質確認
↓
承認
↓
リリース
というように、それぞれの工程があります。
さらに、
開発する人
レビューする人
品質を確認する人
セキュリティを確認する人
最終判断する人
など、それぞれ役割があります。
問題が見つかれば、
レビュー
↓
問題発見
↓
開発へ戻す
↓
修正
↓
再レビュー
となります。
つまり、人間の仕事も、
LoopとGraph
で構成されていると考えることができます。
AIエージェントでも、同じような仕事の仕組みを作れるようになってきているわけです。
「AIにコードを書いてもらう」だけではなくなる
スクールでアプリ開発を勉強していると、
「もっとコードを書けるようにならないと」
と思うことがあるかもしれません。
もちろん、コードの知識はこれからも重要だと思います。
でも、AIの進化を見ていると、それだけではなくなってきています。
AIがコードを書く
↓
AIがテストする
↓
AIがレビューする
↓
AIが修正する
↓
複数のAIが役割分担する
↓
人間がその仕組みを設計する
そうなると、人間には、
何を作るのか
何を正解とするのか
どんなルールで作るのか
AIに何を任せるのか
どこで人間が判断するのか
どうやって品質を確認するのか
を考える力が、ますます重要になるのではないでしょうか。
だから、今勉強していることが無駄になるわけではない
ここで誤解してほしくないのが、
「AIがコードを書いてくれるなら、プログラミングを勉強しなくてもいい」
という話ではありません。
自分はむしろ逆だと思っています。
コードを学んでいるから、AIが何をしているのか理解できる。
APIを学んでいるから、システム同士のつながりを考えられる。
データベースを学んでいるから、データの流れを考えられる。
GitやGitHubを学んでいるから、AIを開発工程の中に組み込める。
UI/UXを学んでいるから、「動く」だけではなく「使える」を考えられる。
テストを学んでいるから、AIに何を確認させればいいか考えられる。
つまり、今学んでいる知識は、
「全部自分で作るための知識」
だけではなく、
「AIと一緒に良いものを作るための知識」
にもなっていくのだと思います。
「作る力」から「仕組みを作る力」へ
自分が特に面白いと思っているのはここです。
これまでは、
人間
↓
コードを書く
↓
アプリを作る
という形が中心でした。
AIが発達すると、
人間
↓
目的・ルール・評価方法を考える
↓
AIが働く仕組みを作る
↓
AIが実装・テスト・レビュー・修正
↓
人間が判断する
↓
プロダクトを作る
という形が増えてくるかもしれません。
人間がすべての作業をするのではなく、
「どうすれば良い仕事ができるのか」という仕組みを人間が考える。
これはソフトウェア開発だけの話ではないと思っています。
会社の業務改善やDXでも、
現在の仕事を理解する
↓
課題を見つける
↓
仕事を分解する
↓
AIに任せられる部分を考える
↓
AI・人間・システムを組み合わせる
↓
新しい仕事の流れを作る
という考え方ができるからです。
AIの進化が本当に止まらない
少し前まで、
Prompt Engineering
という言葉をよく聞いていました。
そこから、
Context Engineering
AI Agents
Multi-Agent
Loop Engineering
Graph Engineering
と、AIの使い方そのものがどんどん変化しています。
もちろん、これらの言葉をすべて覚えることが大切なのではありません。
特にLoop EngineeringやGraph Engineeringは比較的新しい表現でもあり、今後、呼び方や定義が整理されていく可能性もあります。
大切なのは、
「また新しい言葉が出てきた」
ではなく、
「AIで何ができるようになっているのか」
を見ることだと思います。
半年後には、また違う景色になっているかもしれない
AIの世界は、本当に変化が速いです。
AIに質問する
↓
AIにコードを書いてもらう
↓
AIに自分で確認・修正してもらう
↓
複数のAIに役割分担してもらう
↓
AIが働く仕組みを人間が設計する
ここまで、ものすごいスピードで進んできました。
半年後、1年後には、また違う開発方法が当たり前になっているかもしれません。
だからこそ、
「また新しい技術を覚えないと……」
と身構えるのではなく、
「今度はそんなことまでできるようになったんだ！」
くらいの気持ちで触れてみる。
そして、
「今、自分たちが学んでいることとどう組み合わせられるだろう？」
と考えてみる。
それも、AI時代の大切な学び方なのではないかと思っています。
みなさんは、
Loop Engineering
Graph Engineering
という言葉を知っていましたか？
自分もまだ勉強中です。
新しい技術を追いかけるというより、
AIによって「できること」がどう変わっていくのか。
これからも楽しみながら追いかけていきたいと思います。
AIの進化、本当に止まりませんね。
要約
コメント
まだコメントはありません。
