最近の人間ボトルネック問題解決の工夫

2026年9月14日 14:39

最近、同じ会社の別の部署の人から、タイトルの問題で質問されたので、折角なのでブログにも書いておこうと思う。ちなみにこの記事は、AIをつかっておらず、人間が書いています。（元々私はブログにはAI使っていません）

作成 PR をどこまで理解するか問題

　これも難しい話です。現在のところはノールックで Approval は危険です。だからといって、エージェントの生産量に対してすべてのコードを理解するのも、これまたどうなんだろう？というところもあります。これは自分が作ったものの理解も同様です。「理解」は最高の生産性ツールですが、自分のキャパを超えるものは無理があります。

Agent Slop を生み出さないを基準にする

　この辺りを、メンターのクリスに聞いたところ意外な言葉が返ってきました。「自分はもうコードは基本的に読んでいないよ」ただし、「アーキテクチャの主要な部分は理解している」とも言っていました。面白い基準が「Agent slop（エージェントが生産したゴミ）を生産しないようにしている。だってそんなの出すと、自分の評判が傷がつくから。エージェントが普通にやると、PR のディスクリプションも長いしノイズだよね。また、文書やコードの英語も、わかりにくいのが多い。

　私が、自分はネイティブじゃないから、自分より AIの方が完全に上やから彼らのいう事信じてたわと言ったら、ネイティブからするとわかりにくいのがよくあるよ。だから次のようなプロンプトを GitHub Copilot App に入れているんだと言っていました。そんな規格があるとはしらなんだわ。

Use ASD-STE100 Simplified Technical English for all English prose, whether in PR comments, documentation, direct responses, etc.

　Agent Slop を作成しないために、プロンプトを打つまでが相当に慎重にやっているという話をしていました。なぜ、この慎重さが必要か？というと、結局 Agent Slop 的なものを作ったら、PRのレビューで沢山コメントがついてなかなかマージされないことになります。
　彼は最近は別チームに移ったので、彼にとって新しいリポジトリに貢献していますが、彼をもって「１日１ＰＲぐらい」と言っていました。しょうもないものを沢山作るより、１日１PRで良いのでしっかりと、人が読んでわかりやすいものを作るのが結局速そうです。（繰り返しますが、少なくとも今のところ。また、作ってるものによって数も違うとは思います）

エージェントのオーバーエンジニアリングを防ぐ

　ちなみに、うちのチームの場合、ハーネスでFRD を先に書くというルールでこのリポジトリにはとても良く機能しています。

　一方で、他のリポジトリでその戦略を試すと、オーバーエンジニアリングになりました。（もしくは GPT-5/6 系の特性かもしれません、もしくはハーネス問題）いづれにせよ、すべてに適用できる戦略はおそらく存在せず、そのリポジトリの特性を見ながら少しづついろんな事を試してみるのが良さそうです。ハーネスは、定期的に見直す方がよさげなので、私も今週はそういう作業をしています。また、プロンプトやスキルで、オーバーエンジニアリングにならない為、シンプルな事をしてほしい時は具体的なツール選択やアーキテクチャを指示したりしています。

エキスパートでない自分はどうしたらええんや？

　さて、残念ながらうちの事業部の中でエース格のクリスと、アホにゃんにゃんで経験も少ない私では同様に考えてはいけないところもあります。彼は既に何こものフラッグシップのサービスを彼が考えて作っています。つまり、経験もアーキテクチャに関する知識も私とは段違いです。エージェントは自分の物事の理解の「解像度」を反映します。だから、私が彼と同様の指示を与えてるとも思えません。まだつよつよでない人は、自分自身を強くする必要があります。その時に、もうエージェント時代でコードを書かないのでどうやって「アーキテクチャがどうなってる？」という概要でも理解するか？という問題があります。

　エージェントにチュートリアルを作ってもらう

　私の最近やっていい感じなのは、「エージェントにリポジトリのチュートリアル」を作ってもらうという作戦です。例えば私は、Hosted Skills というプロジェクトに貢献していますが、私は後から入ったし、Python はど素人なので、当初自分がコードレビューするときもアホほど時間がかかっていました。なぜなら、少し理解しようとすると、そこからさらにわからないことがでてきて、さらにそこから、、、といわゆる「ヤクの毛刈り」状態になるからです。
　かずき師匠に相談したら、「ヤクの毛刈りすればよい」と言ってくれました。いづれにしても、最近のギターでの気づきで、自分が上達するためには、あるべき姿ではなく、自分の現在地を拡張するやり方が無理がなさそうです。でもヤクの毛がりはしんどいです。

エージェント様に教えを乞う

　だから、どうしたか？というと、リポジトリを参照しながら、エージェントに、「このリポジトリのアーキテクチャ、これ、これ（ここは具体的なものを示す。例えば、エンドポイントの仕組み、エージェントが実行される仕組み、ファンクションが実行される仕組み、、、など）を、構造を保ったまま簡素化して、私が理解するためのチュートリアルを作ってください。と指示する作戦だ。すると複雑なアーキテクチャを紐解いて、エージェント様が、チュートリアルを作ってくれるので、私はエージェントに書かせず、自分の手で入力して、動かして、時には改造して、少しづつ理解するようにしている。

　そうすると、ヤクの毛がりは少なくなるし、知らない事ばかりだと、自分がつらくなるけど、この方法なら、自分が初めてのリポジトリでも、構造を理解した上、あまり慣れていない Python の作法も少しづつ勉強できるし、何より楽しい。自分で手を動かした方が圧倒的に理解しやすいから。

自分がしんどい時は、理解の方法を変える

自分は、何か理解が十分でない時に、例えばコードを読んだりして、「観て」学ぼう、考えようとする傾向が強いが、これは効率がわるいとようやく理解出来てきた。理解するのはゴールデンルールだけど、それは、単に「観る」だけでなくてよい。何か自分がしんどいと思ったら何か間違っている。理解するためには、「読む」だけではなく、「体を使う（つまり自分でコードを書いたりコマンドをたたく」とか、「人に頼る」という事をしても良い。詰まっているとき、しんどい時はむしろそっちのアプローチの方が楽だったりする。

理解のためなら、手で書く方が効率的

　例えば最近ある仕様のものを実装する必要があって、その仕様をしらべていたけど、従来なら、仕様をじっくり理解して、プロトタイプを作って、、、とやるところだけど、先にプロトタイプを「手で」書き始めてやると、理解が「自分のペース」でできるので、エージェントに出してもらうよりずっと楽に感じると思うようになった。
　だから、最近は、わからないことがあるときで、特に理解したいときは、エージェントにお願いして、わかりやすいチュートリアルを作ってもらって自分で手で入力することを良くしている。これをすると、Deep Code Reading も楽だし、自分がレビューするときもかなり楽になって、全部よまなくても、ＰＲの中の「どこを読めばよいか」を理解できるようになったので、今のところは効率がよさそうだ。

エージェントが書けないものは手の方が効率的かも、、、

　実のところ、スキルや、AGENTS.md のハーネス系を書くときも最近は、手書きが多くなってきた。昔はエージェントに食わせて、履歴から作成とか多かったが、最近はモデルも賢くなってきたので、エージェントが探せるものは、だんだん書く必要がなくなってきている。つまり、エージェントが今のところは出来ない明確な指示と、エージェントが知らないドメイン知識、もしくは、エージェントが調査をショートカットできる知識のみで良くて、依然と比べると小さくなっている。つまり、これは、エージェントが答えられるものは、ハーネスとしてあまり価値がないので、人がわざわざ指示しないといけないことは特にエージェントに任せない方が良い気すらする。（もちろんエージェントに調べて、ハーネスを作ってもらう場面は沢山あるけど）

まとめ

　今回のブログは取り留めもない、今のところいろいろ考えている途中のブログだし考えが変わったりもするかもしれないけど、自分の整理として現在いろいろ考えていることを書きました。エージェントの世界は、「変化がある」のを前提に考えた方がよいと思っているので、永遠に通用するノウハウはないので、いろいろ試して、失敗して、少しづつ改善していこう。皆さんにもいい作戦がありましたら、是非教えてください。

ちなみに、最近出た本２冊です。良かったら読んでみてな！
最初の本は、あまりIT関係ない、キャリア戦略とか、自己肯定感のお話です。自分の人生そのものみたいな。

　二つ目の本はあんまりカッコよくない AI ジャーニの話から、AIを使う時に「人間側」がどうするか？という話をかいていますので、もしよかったら読んでいただければ幸いですわ。