第23回Redmine大阪の感想～AIの暴走はチケット駆動で制御する！AI時代に人間が担うべき真の役割は何なのか？ #redmineosaka
AIが開発を自動化する現代、プロジェクトの文脈を知らないAIの暴走をどう防ぐか？
第23回Redmine大阪で語られたRedmineのMCPサーバー化や、制御工学に基づく『チケット駆動によるAI制御』を通じ、AI時代における人間の役割とプロセスのあり方を考えてみた。
Redmine-osaka-023 - Redmine.Osaka
【1】1年ぶりのRedmine大阪のテーマは、やはり「AIｘRedmine」だった。
AIがソフトウェア開発を飲み込んでしまって、AI無しのソフトウェア開発はもうありえない。
プログラミングはもちろん、テスト駆動開発・CI・CD・スペック駆動開発・コンテナ作成・インフラ基盤作成まで全てAIエージェントで自動化できてしまう。
おそらく、タスク管理のような単純なマネジメント作業そのものもAIで自動化されるだろう。
では、現代のAI時代では、何が問題になるのか？
現代のAI時代では、ソフトウェア開発のあるべき姿は何なのか？
【2】@haru_iidaさんの講演で興味を持ったことは、RedmineAIヘルパープラグインにより、RemdineそのものがMCPサーバの機能を持つことだ。
僕はこの意味が即理解できなかったが、 レイリーさん、@akahane92さんの説明により理解した。
RedmineサーバーにMCPサーバー機能をもたせることには2つの意味がある。
1つ目は、RedmineのI/Fがプロンプトを認識できることにより、ユーザはRedmineに自然言語で直接アクセス制御できることだ。
以前なら、REST APIでデータ取得更新するしかなかった。
つまり、REST APIの仕様に従って逐一PythonやRubyのプログラムを書くしかなかった。
しかし、RedmineがMCPサーバー機能を持つことにより、RedmineにあるチケットやWikiなどのPJ情報は、「期日間近のチケットを教えて」とプロンプトを投げればいつでも簡単に取り出せる。
よって、プログラミングを知らない初心者でも、Redmineのチケット情報、ナレッジを有効活用できる。
これはすごいことだ。
2つ目は、MCPサーバをローカルPC上に作成する必要がないこと。
以前なら、ClaudeCodeでRedmineにアクセスしたいならば、自分のPC上にMCPサーバを構築してそれを経由してRedmineやGitHub、Slackなどにアクセスするしかなかった。
逐一、MCPサーバをコンテナ作成するなど手間がかかった。
しかし、RedmineにMCPサーバー機能を持たせることで、ユーザは面倒な作業を除去できる。
この考え方は、一昔前のクライアント・サーバーモデルと同じだ。
クライアント側にビジネスロジックを持たせてサーバーと同期させたり、データの取得更新処理を実行するのではなく、サーバー側にすべての処理を集約させる考え方と同じだ。
一つ疑問点が浮かぶことは、レイリーさんの質問の通り、RedmineにMCPサーバを持たせることにより、セキュリティやアクセス権限制御は大丈夫なのか？という点だ。
どんなPCからも自由にRedmineを簡単に制御させられるのは危険だ。
@haru_iidaさんの回答では、Redmine側のログイン機能やアクセス権限弦制御に従うこと、最新バージョンならOAuth機能も付いているから大丈夫、とのことだった。
【3】@tokudiroさんの講演「AIｘチケット駆動」は、僕が参加者と深く議論したかったテーマ「AIの暴走をチケット駆動で制御する」になる。
アイデアは既に書いた。
チケット駆動でAIを制御する仕組みのアイデア: プログラマの思索
@tokudiroさんの講演を改めて聞いて、ポイントは3つある。
1つ目は、AIは案件のコンテキスト、チームのコンテキスト、ローカルなコンテキストを知らないから暴走しやすいという根本問題だ。
AIはいくら優秀だとしても、彼らは、僕らの案件の詳細を知らないし、僕らの組織にある暗黙知を知らないし、僕らのチームメンバーの癖や暗黙知を知らない。
だから、AIは一般論で突っ走って、僕らが想定しない成果物を出してくる。
そこで、チケットを作業指示書とみなして、作業指示書にプロンプトや前提条件、制約条件を集約して、AIに実行させることでAIを制御する。
プロンプト実行後にAIが出してきた成果物、設計構想、検討結果に対し、人が取捨選択して意思決定し、その履歴はIssueログに残す。
Issueログには、意思決定の履歴が残る。
つまり、意思決定した時にどれを選択したのか、選択した基準は何か、却下した理由は何か、それらのログは全て残る。
それら暗黙知は、プロジェクトのコンテキストそのものだ。
AIはそれらを学習することにより、僕らの癖、価値観をAIは理解して、AIが出す成果物の品質基準を僕らの価値観にできるだけ合わせるように制御できるはずだ。
2つ目は、AIによる処理をチケット駆動で制御する発想は、制御工学の考え方や仕組みにとても似ていることだ。
チケットを作業指示書とみなして、AIの処理を実行させる。
AIの処理結果を人間がレビューして、誤差を検出しAIにフィードバックさせてAIにココが間違えているから直せと再実行させる。
そういうループ処理を回しながら、チケットに本来書き残した目標に近づけていく。
これは、制御工学そのものだ。
講演資料では「AIのプロセスを制御工学に見立てて、AIの思考に物理的なガードレールを設ける」とある。
つまり、AIは暴走しやすいので、チケットとGitHubリポジトリという物理的なガードレールを設けて、意識的にフィードバックループの制約をかけるわけだ。
一方、@hiranabeさんによれば、制御工学は、いわゆる工業製品では当たり前の考え方だ。
たとえば、お風呂の自動湯沸かし器。
お湯が指定した温度で一定量までお湯を張るようにフィードバックさせるが、一定量になれば止める。
お湯を止める制御がなければ、お風呂はお湯で溢れてしまって、水道代が無駄になるだろう。
@hiranabeさんによれば、モノの制御工学では、センサーにより定量的な数値をフィードバックさせて、アクチュエータが力に変えて水量を制御する。
一方、AIによる処理、あるいはScrumでは、ゴールは曖昧で揺れ動くものであるので、定性的なデータをフィードバックして制御するしか無い。
Scrumなら、フィードバックさせるものは人の経験であり、経験を深めることで、特定のコンテキストに対するナレッジを獲得して目標達成に近づける。
【4】懇親会で色々話して理解したことは、チケット駆動でAIを制御する仕組みは、LoopEngineeringとVibeCodingの間に位置し、AIにすべてを委ねず人間が関与すべきプロセスを明示した点だ。
いわゆるルーチンワークのような業務的意思決定は、もはやAIで全て自動化できるだろう。
しかし、事業戦略の判断、アーキテクチャの判断、我々が本来作りたいシステムのあるべき姿に対する戦略的意思決定は、AIは支援できてもAIに全てを委ねて、AIが自動化できることにはならないだろう。
すると、戦略的意思決定のプロセスでは、細かい作業や処理はAIで自動化したとしても、途中でポーズさせて、チェックポイント地点でゲートレビューを設けて、AIの成果物を人間がチェックして、判断するチェックポイントを入れる必要がある。
これこそがAI時代の本来のプロセス設計だろう。
LoopEngineeringでは、このプロセスが全てAIで自動化されるがやはり怖い。
そこで、人間がゲートレビューする出番をわざと作る。
実際、GitHubにおけるプルリクに対するコードレビューが相当するだろう。
この発想は、監査プロセスに対しAIによってどこまでAI自動化できるのか、という問題に発展するだろう。
製造業では、人命・品質に関する規格により、製品も製造プロセスも制御されている。
一定の品質の製品でなければ、人が怪我をしたり命に関わる事象に陥る。
製造プロセスをできるだけAIで自動化したとしても、AIが作り出した製品の機能が本当に品質担保できているのか？を人間が監査して承認を取る必要がある。
つまり、ゲートレビューは監査プロセスで必要だ。
しかし、監査でAIが作り出した成果物の中身を人間が全て理解してチェックできるのか？
@sakaba37さんや@hiranabeさんの意見を聞く限り、AIが出す成果物は膨大なので人間は全てをレビューできない。
しかし、監査プロセスという手続きが妥当であること、サンプルとして取り出したエビデンスが妥当であることが分かれば、AIの成果物の品質も妥当だと判断できるだろう、とのことだった。
つまり、監査とは結局、プロセス監査に過ぎないので、標準プロセスとして定めた監査プロセスが妥当であるならば、その手順に沿ってAIが実行されたことをチェックするだけに過ぎないわけだ。
すなわち、AI時代の監査プロセスは、従来通りのやり方で基本は残るだろうと考える。
【5】@kazuhitoさんの議論で面白かった点は、人がコードレビューしなくなる時代はもう近づいているだろうが、人がコードレビューしなくなる基準は何なのか？という点だ。
今まさに、AIがソフトウェア開発を完全に飲み込んでしまっている。
AIのソースコードは膨大なので、人はすべてを読めないし理解できない。
また、AIが出すソースコードの方が、自分が書いたソースコードよりも凄いぞ、と認識を改める場面も多くなっているだろう。
つまり、AIの成果物の方が品質が良いのだ。
すると、人はコードレビューする能力をそもそも持っているのだろうか？
コードレビューはもはや単なる承認する儀式に過ぎないのか？
@sakaba37さんの意見によれば、アセンブラの頃のプログラミングやテストに似ていると言う。
アセンブラは機械語なので人間には読みにくい。
しかし、デバッグが必要な場面もある。
すると、人は、あるチェックポイントでゲートレビューしてレポートを出させて、成果物そのもののアセンブラは見なくて、レポートだけで判断する。
そのレポートを見ながら、デバッグの指示を出しデバッグのフィードバックを繰り返して、期待する処理に近づける。
その話を聞いて、僕は、結局、AI時代の監査プロセスと同じだな、と思った。
結局、AIの成果物の中身まで人間は全てを把握することは諦めるしか無い。
人間は、手続きというプロセスが正しいことを信じて、承認という判子を押すだけの存在になるしか無い。
AI時代のプロセスは、プロセスの中で実行される処理を見るのではなく、処理を実行させる元のプロンプトに妥当性があることしか、人間はチェックできないだろう。
すると、コードレビューしなくなる基準は、AIによるコード生成のプロンプトによって実行されるプロセスそのものの妥当性が保証される状態を指すだろう。
つまり、プロンプト群から生成されるAIの処理に再現性があり、一定品質をクリアできるならば、もはや人間が関与する必要はない。
たとえば、自動運転技術が最たる例になるだろう。
人間が運転するよりも、AIで自動運転するほうが交通事故が少ないならば、その方が人命は安全だからだ。
つまり、人間が変にこだわって意思決定する行為は、もう無くなる可能性もある。
【6】@kazuhitoさんの話でもう一つ面白かった点は、AIとの付き合い方は、オフショア委託や下請け委託と同じように考えたほうがいいですよ、という主張だ。
たしかにそうだ。
今、ソフトウェア開発をAIで全振りした場合、発注者である自分は、AIに、これこれの機能を実装せよ、こういう品質をクリアせよ、とたくさんの制約条件や前提条件を書いて、指示を出す。
AIは、プロンプトという契約に沿って、成果物を作り出す。
AIが出して来た成果物を人間はレビューして、気に食わなければ、AIに突き返す。
AIはまた修正して、人間にレビューを依頼する。
AIと人間のループ作業によって、最終的に欲しい成果物が得られる。
この関係は、請負契約や業務委託契約に似ている。
AIが作り出す成果物が品質基準をクリアしなければ突き返すならば、請負契約と同じだ。
AIに壁打ちして、企画構想やアイデアを具体化していく作業を行うなら、AIに一定期間のコンサル業務を業務委託契約している感覚だ。
一方、AIは人間と違って、24時間365日フル稼働できるし、こちらの要望に沿ってすり合わせしてくれるので、優秀なオフショア委託ベンダーみたいなものだ。
他方、AIは責任を負わない。
たとえば、インドや海外のオフショア委託ベンダーが期限までに間に合わければ、発注者はペナルティを課し、損害賠償させる契約を結んでリスク回避させることもできるが、AIにペナルティを課して損害賠償させることは出来ない。
AIは、こちらが頼んだ成果物と違うといくら言っても、プロンプトを投げれば即座に成果物を作って送り返してくるので、納期までに間に合わないリスクは、結局、発注者である自分に戻ってくる。
そんなことを考えると、AIを上手く使いこなせる人は、発注者として下請けを上手く操れる手配師みたいな人の方が向いているのかもしれない。
でも、その考え方は何故かしっくり来ないけどね。
【7】AI時代のRedmineの課題は、今までの常識では通用せず、AIの処理の速さによりボトルネックが自分自身に跳ね返ってくる点にあるのだろうと思う。
問題となるボトルネックは、システムではなく、人間の思考や行為そのものに存在する。
たとえば、Redmineがいくらナレッジ基盤として優秀であっても、人間がチケット入力しないと意味がないし、チケット運用する必要もある。
本来はRedmineチケット管理でもっと管理作業を効率化したいのに、AIやRedmineがすごく優秀になりすぎると、人間自体がボトルネックになってしまうわけだ。
僕が考えているテーマは結局下記の2つだ。
現代のAI時代では、ソフトウェア開発のあるべき姿は何なのか？
監査プロセスに対しAIによってどこまでAI自動化できるのか？
この辺りの問題解決のアイデアは色々考えてみる。
最近のコメント