こんにちは、エンジニアの toki (@tokai235) です。法人向け eギフトサービス giftee for Business の開発をしています。普段はバックエンドやインフラのお仕事が多いですが、フロントエンドも好きです。
この記事は、ギフティ Advent Calendar 2025 の 18日目の記事になります。
突然なんですが、みなさんは何かを「まかされた」ことってありますか？
仕事であったりプライベートだったり、いろんなところで使われる概念だと思います。なんですがこの「まかせる」って言葉、すごくふわっとしてないですか？似たような言葉で言うと「裁量」とか「責任」とかもそうかなと思うんですが、正直よくわからない。自分も長いこと雰囲気で使っていました。
でも社会に揉まれながらなんとかやっていくうちに、今は「なんとなくこういうことかな」という持論を持っていて、これに結構助けられています。
せっかくなので今回はその持論を言語化してみようと思います。
AI Agent での経験
実は最近この「まかせる」について説明するいい例があります。Cursor や GitHub Copilot、Claude Code などの AI Agent によるコーディング補助です。
ここからはあなたが「まかせる」側、AI Agent が「まかされた」側だと思って読んでみてください。
初期の AI Agent は PC へのいろいろな操作に対してユーザーの承認が必要でした。AI Agent に「このブランチでこのコードをこんな仕様にしたいから、そのための変更をしてくれ」とお願いすると、AI Agent はものすごい速度でタスクを実行してくれて、そしてすぐにあなたに承認を求めます。あなたは AI Agent にタスクをやってもらっている間、他のタスクに手を付けようとしますが、Agent からの承認依頼がひっきりなしに入るので、他のタスクに手を付けられません。
そうこうしているうちに、AI Agent に Auto Approve 機能が出てきました。これは始めに AI Agent に必要な権限を付与しておいて、操作のたびにユーザーに承認を求めなくて済む、という機能です。あなたは AI Agent にコマンドの実行権限を付与して作業をしてもらいました。AI Agent とあなたはそれぞれがタスクを実行し、仕事はうまく進んでいましたが、AI Agent がタスクを実行中に rm -rf /（PC 内のファイル全削除）を実行してしまいました。PC 内のデータは失われてしまい、あなたは PC を初期化した後、AI Agent の Auto Approve 機能を使わなくなってしまいました。
これらはまさにうまく「まかせられていない」ケースで、人間同士でも起こることです。
「まかせる」ときは「決める(やる)境界」が大事
先程の AI Agent の例はどこがまずかったのでしょうか？
私は「どこまで自分で決める(やる)のか」の境界が「まかせる」側、「まかされた」側でギャップがあったことだと思っています。
初期の AI Agent の例では、
- 「まかせる」側(あなた): ブランチ内で起こることであれば好きにやっていい
- 「まかされた」側(AI Agent): すべてのファイル変更やコマンド実行は承認が必要
というギャップがありました。
Auto Approve の例では、
- 「まかせる」側(あなた): ブランチ内で起こることであれば好きにやっていい
- 「まかされた」側(AI Agent): すべてのコマンド実行に対して承認は不要
という感じですね。私が思うに、「まかせる」のがうまい人、「まかせられる」のがうまい人は、この「決める(やる)境界」をすり合わせたり、読み取るのがとてもうまいと思います。「まかせる」のむずかしさはここのあいまいさが大きいんじゃないかと思いますね。
ちなみに AI Agent の世界ではこのギャップを埋めるために、その後 Devin のようなリモート実行環境型の Agent が登場しています。Devin はリモートマシン内では自由に Agent がタスクを実行して、変更が完了したら Pull Request などでお知らせしてくれる。これはかなり私たちが想像していた AI によるコーディングの体験に近いのではないかなと思っています。ここでは割愛しますが、ローカル開発でも Docker コンテナなど独立した環境を用意して AI Agent を使うといったやり方も試されていたりしますね。
ビル・ゲイツ氏の花束のエピソード
また別の例を挙げると、この手の話で私が好きなのが、ビル・ゲイツ氏の花束のエピソードです。Windows 95 の開発者である中島聡さんの著書「なぜ、あなたの仕事は終わらないのか」で紹介されているエピソードを一部引用して紹介します。
たとえばあるパーティーがあるときに、ビル・ゲイツがあなたに花を用意してほしいと頼んだとします。あなたは花屋に電話をし、パーティー会場に花束を届けるように注文します。しかしパーティー当日、花屋から、雪のせいで配達が遅れるという電話が来ます。
あなたは花が遅れるという旨をビル・ゲイツに伝えます。こういうとき、彼は尋常じゃないほど怒ります。（中略）
あなたが命じられた任務はパーティーに花を用意することであり、花屋に注文をすることではありません。（中略）いかなる理由があっても花を用意することができなかったのは100％あなたの怠慢であり、責任を負うべきだというのです。
ここで「まかせる」側はゲイツ氏、「まかされた」側は「あなた」になるわけですが、ここでの「決める(やる)境界」は
- 「まかせる」側(ゲイツ氏): 手段を問わず、パーティーに花を用意すること
- 「まかされた」側(「あなた」): 花屋に注文をすること
となってギャップが発生し、それによってゲイツ氏は怒ったというわけです。逆に言えば花さえ用意できれば、パーティー会場の裏で昼寝をしていてもいいのです。これが私の考える「まかせる」のメカニズムです。
でもどうしたらええねん
さて、ここまでで「まかせる」をうまくやるには、「決める(やる)境界」のギャップをなくすことが必要だとわかりました。ただこれは、言うは易く、行うは難し、というやつです。
まずここをすり合わせることを考えると、このやり方は会社のスタイル(トップダウン、ボトムアップなど)によっても違いますし、そもそも何が起こるかわからないビジネスの世界で、事前に正しい範囲にだけ権限を渡しておくというのはとても難しいです。これは例えば身近な例で言うとソフトウェアや SaaS のユーザーの権限管理などがイメージしやすいかなと思いますが、すべてのユーザーに対して最小限の権限を正しく管理し続けることはめちゃくちゃ大変ですよね...。あれと同じことを言っています。
なので現在の社会ではトップダウンで職能やルールをはっきり決めたり、各個人が読み取る力をつけることで解決しているように見えます。
では「読み取る力をつけると言っても一体どないすればええねん！」という方も多いんじゃないかと思います。ここはケースバイケースで難しい...なんて言ってしまうとこの記事の意味がなくなってしまうので、持論ではあるのですがある程度の指標はありそうだ、という話もしようと思います。
私が思っているのは、基本的には「まかされた」以外の人に影響がある / ないが一つの境界線になるということです。
例えばさっきの AI Agent の例で言うと、割り当てられたブランチ内でコードを変更する分には他に影響しないので好きにやっていいと思います。ただ、そのブランチを main にマージするタイミングでは承認が必要になるかもしれません。これは本番アプリケーションにコードの変更が入るためですね。PC 内のファイル全削除は、他の AI Agent や PC の所有者にも影響があるので自分の判断だけでやらず、影響を受ける人たちに事前に通知すべきでしょう。
この動き、なんとなくピンと来ませんか？「まかせる」というと上司と部下の関係を思い起こしがちですが、こう書くとこれはソフトウェアの世界で普通に行われていることですね。
- 別システムとの連携で、API のスキーマを変更するときに関係者に相談する
- 密結合になっているモジュールを疎結合に分割したり、それぞれのモジュールの責務を明確にする
これは一例ですが、私たちソフトウェアエンジニアは依存や結合、連携という言葉を普段強く意識していると思います。それがチームや組織においては「裁量」や「責任」という言葉で表されているのです。
そもそもなぜ「まかせたい」のかを考えてみると、一人では手が足りないから人を増やして分担したい、でも全体として力を合わせて同じ方向に進みたい、という気持ちがあります。なので「自分のことは自分で決めて」「他人に影響があるものは伝える」というのが基本姿勢になると思います。
まとめ
今回の記事では「まかせる」について話しました。
「まかせる」というのはチームや組織がより大きくなるために生み出した賢いツールです。うまく使ってみんなで遠くにたどり着いていきましょう。
ギフティでは、まかされたい！やるぞ！という方を大募集しています。興味がある方はぜひカジュアル面談などでお話しましょう！
