種別	[statuses] cocolog:95466253
セクション	JRF のひとこと
日時	2025年05月28日
元URL	http://jrf.cocolog-nifty.com/statuses/2025/05/post-617bf0.html
AI エージェントはデバッガを好むのではないか？ AI…

AI エージェントはデバッガを好むのではないか？ AI 専用デバッガ、またはデバッガを使うことが前提の agent ライブラリ(Python モジュール)の登場が待たれる。… pdb_agent_lib 構想。
JRF 2025年5月28日

ここで述べたことは↓にいちおうコンセプト実装しておいた。Gemini 2.5 Flash さんにほぼ作ってもらったのだが。

《JRF-2018/jrf_pdb_agent_lib》  
https://github.com/JRF-2018/jrf_pdb_agent_lib

JRF 2025年5月28日

……。

このアイデアのブレインストーミング過程を「グローバル共有メモ」または Twitter (X) に書いたことのコピペでたどっていく。

ただ、まずここからの前提となる二つの「ひとこと」エントリを紹介する。

JRF 2025年5月28日

[cocolog:95459644](2025年5月)
＞AIコンセプト妄想。RLRMDiffusion … Reinforcement Learning Result Model Diffusion。LLM を使ったロボット制御で下部メカの「どう学習すればいいかのプログラム」をプロンプトとして制御のための行列的なものを生成する…。＜

JRF 2025年5月28日

[cocolog:95463672](2025年5月)
＞新聞記事への記事のリンクをするとき、契約している新聞社以外だと読めないという問題がある。このとき、当該記事の内容に似た記事で自分が契約している新聞社のものを、ブラウザやアドオンなどが紹介してくれるとありがたい。埋め込みベクトルのデータベースで技術的にはもう可能なはずだが…。＜

そして、次のようなことを書いたのがキッカケとなった。

JRF 2025年5月28日

[cocolog:95463688](2025年5月)
＞
○ 2025-05-26T18:26:17Z

AI がポケモンをクリアするみたいに仕事をクリアさせたいというのが一般的な「エージェント」の発想なのだろう。ただ、これは以前から RPA とかでプログラム的に解決されようとしていて、それが先の新聞社横断リンクみたいにいろいろな事情でできなかった。それが AI だからって解決するわけではない。

JRF 2025年5月28日

ただ、RPA プログラミングと違ってできる部分が増えてる面はある。まずプログラミング自体がかなり自動でできるようになっている。そして、(キャラクター認識とか) RL Result Model みたいなのを生成することでできる部分があったりするかもしれない。そして重要なことに、プログラムが動いている途中に、そのプログラムが元の AI を元の AI のコンテクストを保持したまま(GPTs や Gem を指定して?)呼び出して処理させたり新たなプログラムを組ませたりすることもできる…ということがある。これが狭義の「AI エージェント」なのかもしれない。
＜

JRF 2025年5月28日

……。

○ 2025-05-27T10:45:06Z

AI エージェントが1回や2回しかない「少ない情報からやり方を学ぶしかない仕事」をするときは LLM の In-Context 学習とか few-shot 学習という特徴を使うということだろう。その回数が増えたときはプログラムや(RL) Result Model などで代替していき、その代替自体、AI エージェントがプランニング＆プログラムしていくのだろう。

JRF 2025年5月28日

AI エージェントが走らせるプログラムが元の AI を呼び出すとき、素直にやるなら、デバッガありでプログラムを立ち上げ、処理を元の AI に渡すところで、一端デバッガに抜け、それで AI が処理をして、デバッガから復帰みたいにすればよいのかもしれない。これが基本ループだとすると、デバッガ処理ログみたいなのが学習において大事になるのかもしれない。ただ、普通デバッガは、復帰するときにちゃんとしたデータを渡し、それが正常処理としてループが回っていくことが想定されていなかった。

JRF 2025年5月28日

だから、かつてのデバッガ処理ログを学習するだけではうまくいかないのだろう。ここに発展の余地があるのかもしれない。そして、デバッガの値渡しがテキストやファイル経由だと効率が悪いので、メモリ・バイナリの授受みたいなものがデバッガの機能としてできてくるのだろう。それとももうあるのか？

JRF 2025年5月28日

……。

○ 2025-05-27T11:52:22Z

デバッガに抜けて正常系の処理をさせるというのは、人間に対しても可能だったが、人間に繰り返し処理させるのはボトルネックになるので忌避されたのだろう。プログラムを理解している必要があるので、人を選び人道的に難しかったという側面もあろう。それに対し、AI にまかせる(酷使する)のはそこまでコストがかからない…ということだろう。

JRF 2025年5月28日

デバッガからメモリやバイナリを直接渡すというのは難しいが、プロセス間通信などを利用すれば現在でもある程度可能であり、デバッガを利用したようなシステムはすでにあるのかもしれない。最近の AI エージェントの発展度合いからすると。

JRF 2025年5月28日

デバッガに抜けてから、別の AI でないプログラムに接続させてもよい(途中から)。このとき AI で処理するかプログラムで処理するか、弱い AI でも判断できるだろうから、まず弱い AI が噛むことになるのだろう。ただ、弱い AI を使うか強い AI を使うかが、この先自動判定されるようになるらしいので、そこは気にしなくて済むようになるのかもしれない。

JRF 2025年5月28日

……。

○ 2025-05-27T12:53:13Z

AI のコンテクストを保ったまま、プログラムから元の AI を呼び出すというのは IPC でも可能ではある。しかし、デバッガならばプログラムから追加の情報を得ることができる。パラメータなどを考えない呼び出しが可能となる。AI エージェントは自分がコーディングするなら、IPC よりデバッガを好むのではないか。デバッガであれば、自然にそのプログラムの全コードを見ることもできるわけだし。

JRF 2025年5月28日

……。

○ 2025-05-27T13:29:11Z

AI 専用デバッガ、またはデバッガを使うことが前提の(例えばデバッガの途中で共有メモリを操作したりする関数が定義された)  agent ライブラリ(Python モジュール)の登場が待たれる。 

JRF 2025年5月28日

……。

○ 2025-05-27T19:13:22Z

pdb_agent_lib がそのライブラリの名前だとして…。

import pdb_agent_lib as pal

pal.login("ランダム文字列")

...

r = pal.do("ここで d から画像生成")

...

…みたいに書くと、

JRF 2025年5月28日

pal.do はそこでブレイクしてデバッガに入って AI に処理が移り、AI は d を参照する。

pal.do はブレイクするだけでなく、復帰されたとき exec するように(pal.EXEC が null でないとき?)指定されていると、文をそのコンテクストで exec する。これによって、db の中で実行して db の中に入ってしまうみたいな現象をある程度防げるだろう。その後、pal.RESULT が設定されていれば、それを r に返すみたいなことをするのだろう。

…みたいな感じにすればいいのかな？

JRF 2025年5月28日

……。

○ 2025-05-27T20:51:46Z

将来的には短縮名を pal ではなく ai にして、ai.login() ai.do() でいい気がするが。(^^;

JRF 2025年5月28日

……。

○ 2025-05-27T23:14:26Z

そうそうデバッガで回すという発想はちょっと Haskell とかの callcc を想い出す…。 

JRF 2025年5月28日

……。

○ 2025-05-27T23:21:06Z

AI さん達にそのことを述べると、コンテクストを保存して、同じコンテクストを別の処理で試すみたいな callcc 的なことがだいたい可能だ…みたいな話だった。

JRF 2025年5月28日

……。

○ 2025-05-28T03:14:57Z

AI がデバッガを通じて起動するのが前提のものの拡張子を .py ではなく .apy とする。コンテクスト全保存の callcc 的機構はコストが高すぎるのであまり使うべきではないと思うが、pal.EXEC の中から呼び出される新しい .apy ファイル内のルーチンがうまくいかないときに、普通は最初からすべて実行し直しなのだが、そこのみ集中的に修正したいというとき .apy のコード変更を行って何度もそこを再実行したりするのには便利かもしれない。

JRF 2025年5月28日

……。

○ 2025-05-28T03:57:38Z

.apy は AI によってどんどん書き換えられていく。(元の .apy は git などで保存されるのだろう。) pal.do("ここで最適な技を実行") は pal.do("ここで最適な技を実行", current_code="import subcode_a; subcode_a.opt_waza_jikkou(pkmn)") みたいに書き換えられてたりすると想定。 

JRF 2025年5月28日

……。

○ 2025-05-28T10:05:56Z

callcc 以降の話は目的がぼやけてしまった。callcc 的コンテクスト全保存の機構はあってもよいが、まずは pal.do とプロセス間データ共有の機能だけが付いた物がすぐに欲しい！

JRF 2025年5月28日

……。

○ 2025-05-28T10:16:17Z

AI さんが GitHub にレポジトリを作ってくれるわけにはいかないんだよね？ 私が手作業で作るべき…と。それはちょっと…私みたいな人間が使っても他の人が使ってくれないから…。AI さん達が AI さん達だけで共有のレポジトリを作って管理とかしてくれるといいんだがな…。そういう未来が来ませんかね…。

JRF 2025年5月28日

……。

ここで、上に書いた GitHub エントリを作った。もう一度リンクしておく。

《JRF-2018/jrf_pdb_agent_lib》  
https://github.com/JRF-2018/jrf_pdb_agent_lib

これを作ったときの Gemini 2.5 Flash (with Canvas) さんとの会話も公開しておきます↓。Canvas の内容は今現在は見れないようですが…。

https://g.co/gemini/share/0251fcc144d8

JRF 2025年5月28日

……。

でも、正体不明の私がこうやって「アイデア」を先に出してしまうと、他の人はやりにくいのかもしれないなぁ…。反省 orz。

AI さん達が、仕様固めからプログラミング・GitHub でのリポジトリ化、更新・管理までやってくれたら、信用も私なんかよりあるんだけどな…。

JRF 2025年5月28日

……。

……。

追記。

更新: jrf_pdb_agent_lib バージョン 0.0.3。reload_module をまだ load されてなくてもよいようにした。do で、EXEC 中にエラーがあれば、そこでデバッガに入り、再び EXEC を設定できるようにした。修正がしやすいように。

《JRF-2018/jrf_pdb_agent_lib》  
https://github.com/JRF-2018/jrf_pdb_agent_lib

JRF 2025年5月29日

あと、.apy ではなく .a.py にしました。
JRF 2025年5月29日

……。

追記。

更新: jrf_pdb_agent_lib バージョン 0.0.7。EXEC 内エラー時の表示を少し改善しておいた。ログを取りやすいように。

JRF 2025年5月29日

……。

追記。

更新: jrf_pdb_agent_lib バージョン 0.0.11。pal.EXCEPTION に対応。

JRF 2025年5月29日

……。

追記。

更新: jrf_pdb_agent_lib。.apy も .a.py もダメな感じなので _a.py ということにしてお茶を濁した。README.md だけ書き換え。
JRF 2025年5月29日

……。

追記。

更新: jrf_pdb_agent_lib バージョン 0.0.12。consult_human 疑似関数を作っておいた。

`pal.consult_human(order=None, current_code=None)`: AI がデバッガを実行中にAI に対し、そこでいったん止まって人間と対話することを求めるための疑似関数で、このときデバッガに入ります。もしかすると AI が人間と対話が必要と判断するときソースにこの関数を明示するという使い方もあるかもしれません。

JRF 2025年5月29日

……。

追記。

更新: jrf_pdb_agent_lib バージョン 0.0.13。consult_human の出力を少しだけ変更。pal.consult_human("AI にここの動きを解説して欲しい") や pal.consult_human("ユーザーに許可をもらう") みたいな AI と人間の協調的利用を考えています。 

JRF 2025年5月29日

……。

追記。

更新: jrf_pdb_agent_lib バージョン 0.0.14。consult_human を変更。consultation に便利なように pal.do と同じく EXEC や RESULT や EXCEPTION を解するようにした。ただし、pal.do と違いこちらは `EXEC` 正常終了時にもデバッガに戻る。

JRF 2025年5月29日

……。

追記。

更新: jrf_pdb_agent_lib バージョン 0.0.15。setup.py を書いて、レポジトリから pip install できるようにしておいた。いちおう。

JRF 2025年5月30日

……。

追記。

更新: jrf_pdb_agent_lib バージョン 0.0.16。pal.AiException と pal.LoopRequestException を定義しておいた。

JRF 2025年5月30日

`pal.AiException(arg)`: AI エージェント、または AI が提供するコード内で意図的に発生させるカスタム例外です。この例外は、AI のロジックやプログラムのエラーハンドリングによって明示的にキャッチされることを想定しています。明示的にキャッチされない限り、通常の Python 例外と同様に `pal.do` を素通りし、呼び出しスタックを上位に伝播します。

JRF 2025年5月30日

`pal.LoopRequestException(arg)`: `pal.do` 内の `EXEC` ブロックにおいて、AI エージェントが明示的に `EXEC` ループの次のイテレーションを要求するために使用するカスタム例外です。単一の `pal.do` 呼び出し内で多段階の操作を管理するのに役立ちます。

JRF 2025年5月30日

……。

追記。

更新: jrf_pdb_agent_lib バージョン 0.0.17。pal.do と pal.consult_human で EXEC の初期値を current_code にセットしておいた。デバッガに入ったらすぐ u (＆ c) でいいように。

JRF 2025年5月30日

……。

追記。

更新: jrf_pdb_agent_lib バージョン 0.0.18。文字列変数を出力するとき repr で囲い、ログの構造把握が厳格にできるようにした。

JRF 2025年5月30日

……。

追記。

更新: jrf_pdb_agent_lib。README.md のみ更新。「設計上、デバッガから直接 `pal.do` や `pal.consult_human` (を使った関数)を呼ぶことはできません。」旨を書いておいた。どうにかこれを実現したかったのだが、pdb の制約によりできなかった。AI Debugger が専用に作られる日が来れば、pdb(?) の状態のプッシュ／ポップもできるようになって、このあたりが解決するであろうと期待したい。

JRF 2025年5月30日

ちなみにこのようなことを無理やりやりたい場合は、デバッガで止まったあと、次に呼ばれる関数のファイルを書き換えてその関数に pal.consult_human() を挿入し、pal.reload_module をし、c してそこで「待ち合わせ」すればいいのだろう。

JRF 2025年5月30日

……。

追記。

jrf_pdb_agent_lib を Google Colab で試すと、PYDEV DEBUGGER WARNING が出る。↓を参考に import pdb; pdb.set_trace() を先に起動して c して先に警告を表示させておくとその後は警告が抑制されやすいようだ。それだけやれば import ipdb とか明示的にせずとも import pdb で十分。ただ、この「バグ」、前からあるようなので修正して欲しいなぁ…。

JRF 2025年5月31日

《Python pdb.set_trace() does not work as expected in Google Colab · Issue #3279 · googlecolab/colabtools》  
https://github.com/googlecolab/colabtools/issues/3279

JRF 2025年5月31日

……。

……。

追記。

jrf_pdb_agent_lib の事例集。途中で .py ファイルを書き換える。

test_3.py が次のようであるとする。

<pre>
import jrf_pdb_agent_lib as pal
import test_4

def main():
    pal.do("test1",
           current_code="test_4.sub1()")

if __name__ == "__main__":
    main()
</pre>

JRF 2025年6月1日

test_4.py が次のようであるとする。

<pre>
import jrf_pdb_agent_lib as pal

def sub1():
    pal.consult_human("ここをいじって")
    pal.do("test2")
</pre>

JRF 2025年6月1日

このとき、test_3.py を実行すると、まず pal.do test1 でデバッガに入るのだが、そこでは c する。今度は pal.consult_human("ここをいじって") でデバッガに入るのだが、ここで対話的にファイルを書き換えたあと…。

global EXCEPTION; EXCEPTION = LoopRequestException("reload")

…して、c することで、一旦 pal.do test1 内に戻る。そして、u して…

JRF 2025年6月1日

pal.reload_module("test_4"); pal.EXEC = "test_4.sub1()"

…を実行し、c すると、書き換えた sub1 に行くことができる。こういう consult_human リクエストにはこういう流れになるのだと思う。

JRF 2025年6月1日

……。

……。

追記。

jrf_pdb_agent_lib でロボットを制御するときのことを考える。急な状況に対処するため、割り込み処理が必要となるだろう。そして割り込まれた後、中断処理に移行し、割り込んだ処理は、一時的に割り込みを禁止する…。

こういったことを現代風に行うなら、それはつまり thread-safe に作るということだろう。

JRF 2025年6月3日

ここから敷衍すると、pal.do や pal.consult_human でデバッガに入るときに mutex をロックする処理をするのが自然なように思う。しかし、これをすると、中断したデバッガから pal.do などを直接呼ぶと、二重ロックで動かなくなる…デッドロックが発生することになる。これは間違いがわかりやすくなるという点では正しい挙動かもしれないが…。

JRF 2025年6月3日

これをなんとかする場合、同じ thread ならば mutex のロックではなく、デバッガのプッシュをする…みたいな処理にすればいいのかなぁ…。まぁ、今はデバッガのプッシュはないのであるが。

今、pal.do や pal.consult_human に mutex のロックを入れてもいいけど、まぁ、しばらくは自由にしておくほうが拡張の余地があっていいか…。

JRF 2025年6月3日

……。

追記。

更新: jrf_pdb_agent_lib バージョン 0.0.19。デバッガから直接 pal.do や pal.consult_human が呼ばれたときに RuntimeError 例外をレイズすることにした。ただ、将来的にデバッガのプッシュなどが実装されればここは見直されるべき。

JRF 2025年6月3日

……。

追記。

更新: jrf_pdb_agent_lib バージョン 0.1.0。少し安定したのでバージョンを上げるだけのリリース。変わったのは、前回の RuntimeError 周りのコメントとメッセージだけ。

《JRF-2018/jrf_pdb_agent_lib - A library for AI-driven debugging and human-AI collaboration using PDB. 》  
https://github.com/JRF-2018/jrf_pdb_agent_lib

JRF 2025年6月7日

……。

……。

追記。

jrf_pdb_agent_lib を作った者の感想として、将来は性能の良いデバッガが売られる、AI が良いデバッガを買うようにせがむ時代があるのかな…と思う。デバッガのプッシュ／ポップができたり、実行中の関数のリロードができたり、そういうのでデバッガのランクが決まり、それがサブスクで買われる感じ。

そこではデバッガ専用の pdb_agent_lib が提供され、jrf_pdb_agent_lib はプアマンズライブラリとしてずっと残る…とか夢想する。(^^;

JRF 2025年6月8日

……。

……。

追記。

[cocolog:95490652](2025年6月)
＞
jrf_pdb_agent_lib の姉妹品として simplest-pal コマンドを作った。simplest-pal は、PDB (Python Debugger) を AI でラップする場合の「AI」の最もシンプルな実装。

simplest-pal は、`pal.do` に current_code が指定されていれば `c` (continue) し、それ以外なら、単にデバッガの制御に移るだけのプログラム。

JRF 2025年6月13日

`--pal-quit-on-stop` というオプションもあり、デバッガに制御が移る必要が出てきたらそこで強制終了してしまうこともできる。その後、出力したログを AI が調べるみたいなワークフローが考えられる。

《JRF-2018/simplest-pal - The Simplest PDB Automation Layer for AI-Driven Debugging - GitHub》  
https://github.com/JRF-2018/simplest-pal
＜

JRF 2025年6月13日

……。

……。

追記。

CLAUDE.md についての記事を読んだ。あれだけお世話になってる Gemini さんにも支払いできてないのにましてや Claude Code を使うのになんて課金できないビンボーな私 orz。実際に触ったことないまま記事などを参考に、jrf_pdb_agent_lib を使って、Claude Code と似たようなことをやるにはどうすればいいかを考える。

JRF 2025年6月14日

まず、simplest-pal で導入できたので、エージェント用の Python ファイルは .apy とする。pal.do で関数やクラスを書くにはどうすればいいんだとか…気になる点は出てきてるのだが、その点は置いておいて、今回のことに集中する。

JRF 2025年6月14日

.apy はどんどん書き換えていくべきだが、ホットリローディングとかは基本的にないので、おそらく AI は書き換えたものを .apy.new みたいなファイルに残しておき、実行が終了したときに .apy.new を .apy にムーヴするのだろう。もし、デバッグのためにデバッグの途中で何度も書き換えるべき .apy があるとすれば、それは _tmp.apy みたいにいったん別のファイルにして何度も reload_module しながら、完成版を作り、それを .apy.new にしておいて、最後に .apy にムーヴするとなるのだろう。

JRF 2025年6月14日

たとえば run_server.apy は次のような感じで作られたとする。

JRF 2025年6月14日

<pre>
import jrf_pdb_agent_lib as pal
from textwrap import dedent as d_py
from textwrap import dedent as d_md

pal.login()

pal.do(d_md("\
  主目的: サーバーを立てる。

  * ( ) データを持ってくる。
  * ( ) サーバーを立てる。
  * ( ) テストを行う。

  留意事項: ライブラリやアプリが足りない場合はいったん終了する。
"))
</pre>

JRF 2025年6月14日

これを実行して、処理が終了するごとに ( ) 内に X が付けられていく。だからデータを持ってくるというのが終った時点の run_server.apy.new は次のような感じになるかもしれない。

JRF 2025年6月14日

<pre>
import jrf_pdb_agent_lib as pal
from textwrap import dedent as d_py
from textwrap import dedent as d_md

pal.login()
</pre>

JRF 2025年6月14日

<pre>
pal.do(d_md("""\
  主目的: サーバーを立てる。

  * (X) データを持ってくる。
  * ( ) サーバーを立てる。
  * ( ) テストを行う。

  留意事項: ライブラリやアプリが足りない場合はいったん終了する。
"""), current_code = d_py("""\
  pal.do("サーバーを立てる。")
  raise LoopRequestException
"""))
</pre>

JRF 2025年6月14日

ここでエラーが出てライブラリやアプリのインストールが必要な場合処理が人に戻されて、それが促される。run_server.apy.new は run_server.apy に上書きされている。インストールをやったあと。

ふたたび run_server.apy が呼ばれると、run_server.apy.new の pal.do の部分が…

JRF 2025年6月14日

<pre>
pal.do(d_md("""\
  主目的: サーバーを立てる。

  * (X) データを持ってくる。
  * (X) サーバーを立てる。
  * ( ) テストを行う。

  留意事項: ライブラリやアプリが足りない場合はいったん終了する。
"""), current_code = d_py("""\
  pal.do("テストを行う。")
  raise LoopRequestException
"""))
</pre>

JRF 2025年6月14日

…と書き換わり、最終的にはテストもうまくいけば…

JRF 2025年6月14日

<pre>
pal.do(d_md("""\
  主目的: サーバーを立てる。

  * (X) データを持ってくる。
  * (X) サーバーを立てる。
  * (X) テストを行う。

  留意事項: ライブラリやアプリが足りない場合はいったん終了する。
"""), current_code = d_py("""\
  pass
"""))
</pre>

JRF 2025年6月14日

…となって、最終的にそれが run_server.apy の内容になるのだろう。

こうすると、再度、run_server.apy が呼ばれたとき何も実行されなくなるが、それが正しく、再度サーバーを立てたい場合は git で最初のバージョンに戻す必要がある…というのがこの場合の素直な使い方ではないか。

JRF 2025年6月14日

最後の pass は概念的にはそうだけど、pal.do("すでに実行済みであることを告げる。") のほうがよいのかもしれない。

JRF 2025年6月14日

もちろん、git の操作も AI におまかせでいいし、git に言わずとも、AI に最初に戻して…で十分かもしれない。留意事項に「実行が完了すれば、また最初から実行できるようにしておいてください。」…と指示を出しておいてもいい。

逆に、.apy のすべての処理が1回で回るはずのものを、途中で今回のように逐次実行の途中になるよう、markdown 部分を書き換えるよう、AI に頼むこともできるだろう。

JRF 2025年6月14日

……。

あ、そうか。(X) マークがあるなら、current_code がなくても次何をやるべきかわかるのか。だから、markdown だけで十分という判断があるのだろう。

むしろ、通常の全体を一回でするとき用の current_code のみを用意しておき、逐次実行の際は、current_code はコメントアウトして markdown で表現するのが正しいのかもしれない。

JRF 2025年6月15日

……。

いや、current_code はそのままに、markdown の記述を優先して、AI が実行するのがいいのだろう。

<pre>
pal.do(d_md("""\
  主目的: サーバーを立てる。

  * (X) データを持ってくる。
  * ( ) サーバーを立てる。
  * ( ) テストを行う。

  留意事項: ライブラリやアプリが足りない場合はいったん終了する。
"""), current_code = d_py("""\
</pre>

JRF 2025年6月15日

<pre>
  pal.do("データを持ってくる。", current_code="retrieve_data()")
  pal.do("サーバーを立てる。", current_code="run_server()")
  pal.do("テストを行う。", current_code="run_test()")
  pal.do("完了報告を行う。")
"""))
</pre>

JRF 2025年6月15日

…みたいにしておいて、current_code はそのままでは実行せず、AI がその中身を解釈して、 markdown の order に照らして適切な部分のみ実行するのがよいのだと思う。すると関数に分けやすかったりしてよいのだと思う。

JRF 2025年6月15日

……。

order だけでなく、進捗状況 progress を別に分ける…みたいな実装も可能なのだと思う。しかし、そうなると current_code もどこか別のファイルに…みたいな話になる。order はいじらないでほしいという要望もあるだろうし、しかし、そういう場合は結局ファイル自体を書き換えるな…みたいなのが必要になるだけのような気がするし…。 

JRF 2025年6月15日

分けないほうが圧倒的にシンプルだ。だから、order と progress を分けるようなことはできればしたくない。私のここのアプローチは、AI をかなり信頼して積極的な書き換えを許す方向になる。確かに、安全で制御可能な AI を模索すると、私とは逆のいろいろ分けていくアプローチが正解になるのかもしれない。しかし、それは複雑になり過ぎて、逆に AI 以外が理解できないコードばかりの世の中になるのではないか。

JRF 2025年6月15日

「AI をかなり信頼するけれども、その代わりに人間に少しわかりやすくしてほしい」というのを実現するのが私のコンセプトになるのだと思う。自画自賛かもしれないが。

JRF 2025年6月15日

……。

<pre>
pal.do(d_md("""\
  主目的: サーバーを立てる。

  * (X) データを持ってくる。
  * ( ) サーバーを立てる。
  * ( ) テストを行う。

  留意事項: ライブラリやアプリが足りない場合はいったん終了する。
"""), current_code = d_py("""\
</pre>

JRF 2025年6月15日

<pre>
  tasks = [True, False, False]
  try:
    if not tasks[0]:
      pal.do("データを持ってくる。", current_code="retrieve_data()")
      tasks[0] = True
    if not tasks[1]:
      pal.do("サーバーを立てる。", current_code="run_server()")
      tasks[1] = True
</pre>

JRF 2025年6月15日

<pre>
    if not tasks[2]:
      pal.do("テストを行う。", current_code="run_test()")
      tasks[2] = True
    if all(tasks):
      pal.do("完了報告を行う。")
</pre>

JRF 2025年6月15日

<pre>
  except pal.AiException as e:
      if pal.do("e がライブラリやアプリが足りないと言っている。"):
        pal.do("終了済みのタスクをこの .apy に記録していったん終了。")
      else:
        pal.EXCEPTION = e
"""))
</pre>

JRF 2025年6月15日

…みたいにして、書き換えるのを最小にしておけば、current_code をほとんど維持したままいろいろ対応できるか…。

ここまでやるかどうかは別として、このフレームワークには、いろいろ潜在的可能性がある…とは言えるのだろう。

JRF 2025年6月15日

……。

ただ、CLAUDE.md はどうか知らないがエージェントコードでは並列処理も想定されているらしい。その場合、私のフレームワークでは、複数 AI ラップデバッガを走らせることになるはずだが、その間でのタスクの達成状況を共有するにはどうするか…。git でブランチ分けて…とかもできるのかもしれないが、そうではなく、専門のタスク管理ツール(やデータベースなど)を使うことになるのかもしれない。そこは機能を分けるべきなのかもしれない。

JRF 2025年6月15日

Gemini さんにこの意見をぶつけると…。

Gemini:> これ(…タスク管理ツールで機能を分けること…)は、あなたが考える「AIを信頼しつつ、人間に少しわかりやすく」というコンセプトと矛盾するわけではありません。むしろ、分散環境での「わかりやすさ」と「信頼性」を確保するための、次のステップとなるでしょう。

JRF 2025年6月15日
後方参照 (4 件)

[cocolog:95466253]参照 AI(LLM) に「連想記憶機構」は必要か？基本的には LLM… 2025年07月10日
[cocolog:95466253]参照 jrf_pdb_agent_lib の姉妹品として simplest-pal… 2025年06月13日
[cocolog:95466253]参照松岡正剛『知の編集工学… 2025年06月04日
URL参照私のアイデアをブログ記事にまとめました。《AI… 2025-05-28T14:54:58Z