AIToday
大規模言語モデルAI安全性・アラインメントZenn AI/ML掲載日時: 2026年10月17日 10:00

人間とAIが変え続ける設計論を提唱

LINEで送る
人間とAIが変え続ける設計論を提唱

3つのポイント

  1. 何が起きたか

    Zennの論考が「Co-generative Systems Design(共生成的システム設計)」を提唱。

  2. なぜ重要か

    設計の中心を完成プログラムから、人間とAIが変え続けるための環境・手順へ捉え直す論点。モデル能力向上で全設計の手作業承認は速度・規模で限界に達しうると指摘。

わからないところ、AIに聞けます

質問と回答はこのページに公開されます。

こういう要約が、毎朝あなたのメールに届きます。

背景と解説

論考はソフトウェア設計を純粋に技術的な営みとして扱うのではなく、建築や都市デザインから発想を借りて議論を組み立てる。ソフトウェア設計がクリストファー・アレグザンダーのパタン・ランゲージから多大な影響を受けてきたこと、Eric Evansのドメイン駆動設計が専門家と設計者の間で共有言語を育てる点を重視する点で共通することに触れる。一方で建物と都市は区別する。建物は完成後に使われ改修されるが、都市には各自の目的を持つ多数の主体がひしめき、誰一人として最終形を確定できない。AIがコードを書く段階を超え、仕様、設計、テスト、運用、さらには次の変更の提案まで担うようになれば、ソフトウェアも同様の性格を帯びうると論考は示唆する。

続いて設計権限を役割に分ける。リードデザイナーはAIに委任する範囲、変更手順、責任の所在を定める。開発者市民設計者は共有メカニズムを拡張・変更する。利用者市民設計者は自らの環境を変え、AIの判断を監視し、異議を申し立てる。AIは委任範囲内で設計・生成・実行するエージェントとして位置づけられる。AIに設計能力を委ねることが人間の参加を狭めてはならないと論考は強調する。

RubyとRailsからは、既存メカニズムを変更する自由を引き継ぎたいとする。Rails Doctrineの「Provide sharp knives」、つまり強力なツールを取り上げるのではなく開発者の判断を信頼する原則を引く。この自由はプログラムを書けない利用者にも広げるべきだと論じ、人間の開発者に強い拡張権限を与えることと、自律型AIに無制限の権限を与えることは異なると注記する。最後に、誰が利用者を代表するのか、異議がAIの高速な変更に追いつけるのか、システムが全体として改善したことをどう検証するのか、といった未解決の問いを残す。

よくある質問
「Co-generative Systems Design」とは何か
完成したプログラムではなく、人間とAIが共同でシステムを変え続けるための環境と手順を設計するという、論考の造語。
論考はどのような役割を割り当てているか
AIへの委任範囲や変更手順、責任の所在を定めるリードデザイナー、共有メカニズムを拡張する開発者市民設計者、自らの環境を変えAIの判断を監視して異議を出す利用者市民設計者、委任範囲内で行動するエージェントとしてのAIに分ける。
論考はどのような例を挙げているか
AIが学習者の学習計画を変更するサービス。学習者は異議を出せ、教師が再確認し、問題の繰り返しは共有ルールの改訂を促しうる。
LINEで送る

あなたの仕事に関係するAIニュースを、毎朝お届けします。

業界と使っているAIツールを選ぶと、仕事に関係するニュースが毎朝届きます。

登録無料・Googleアカウントなら30秒・いつでも解除できますAITodayについて →

AIに質問

この記事についてわからないことをAIに質問できます。AIはこの記事・AIToday の過去記事・Wikipedia を読み、出典を付けて答えます。Q&Aはこのページに公開され、他の読者も読めます。

質問と回答はこのページに公開されます。

関連記事

次の記事へLessWrongが管理役の委任不足を指摘