『Gemini at Work 2026：仕事を任せる「Gemini agent」を発表』 Googleが発表したのは、自分のメールアドレスや役割を持ち、チームに加わるAIだ。PCを閉じても仕事を続け、必要に応じて別のエージェントへ作業を割り振る。「Gemini agent」を、目的を伝えて仕事を任せる共通の窓口にするという構想らしい。 GeminiはGoogleやAndroidにくっついてくるから手軽に使えること以外出遅れてる感があるような気がするけど、今後どうなるんだろうなー。 以下、詳細です。 ・会話が終わっても続く仕事 クラウド上で記憶と実行を維持し、数時間から数日かかる作業にも対応すると説明する。必要に応じて子エージェントを作り、並行作業や順番に進める作業を調整する設計だ。 ・チームに加わるAI Workspaceでは、専用のメール、カレンダー、Driveを持つエージェントを作成できると紹介する。人のアカウントを借りるのではなく、自分の名義で動き、共有された情報にアクセスする。チャットへの追加や文書のコメントから仕事を頼む例が示されている。 ・業務の背景と手順の共有 社内システムへの接続、仕事の手順をまとめたSkills、記憶を組み合わせる。チーム独自のSkillsを社内で共有する仕組みも設ける。データ分析では、指標の定義や業務ルールを参照するKnowledge Catalogを重視している。 ・モデルとエージェントを分ける Gemini agentの裏で使うモデルは、Geminiだけに限定しない。現時点でClaudeも対象とし、他のモデルへ広げる方針だ。仕事に応じてモデルを選び、精度と費用を調整する。 ・権限と行動の記録 各エージェントに識別情報と必要最小限の権限を与え、行動を記録する。コードは隔離された環境で実行し、通信にはAgent Gatewayで組織のルールを適用すると説明している。「何が、何をしてよくて、何をしたか」を管理する設計だ。 ・費用にも上限を設ける プロジェクトごとに利用額の上限を設定し、上限に達するとエージェントを停止する。トークンだけでなく実行環境の費用も追跡し、部門別の費用管理につなげるとしている。 記事はGoogle CloudのCEOによる基調講演をもとにした、自社製品の発表だ。紹介された機能すべての提供時期が明記されているわけではなく、金融・法務向けはプレビュー、政府・医療・小売向けは今後の予定とされている。 自分が見たいのは、AIがチームに加わったときに、人の仕事がどう変わるかだ。目的や完了条件を決め、必要な情報を渡し、結果を確かめる。その分担まで設計できれば、ツールを増やすことから、仕事の進め方を変えることへつながりそうだ。

『システム障害の対応についてエンジニアの約6割が対応しきれないと回答…その要因には即戦力となる人材不足や体制の問題、過酷な労働時間、下請け構造などが考えられる』 障害から復旧できたことと、無理なく運用を続けられることは違う。PagerDutyの調査では、大企業で障害対応を担う316人のうち、66.2%が現体制では「恒常的に対応しきれていない」か「対応しきれないことがある」と回答した。改善・リファクタリングを後回しにした人は50.3%、再発防止策は40.5%。障害対応を続けるために、次の障害を減らす仕事が止まってしまっている。 この報道への反応を集めたTogetterには、開発後に人を減らして知識が残らない、増員しても必要な経験がない、深夜や休日の対応がつらい、といった声が並ぶ。これらは投稿者の経験や意見であり、調査で原因が証明されたわけではない。ただ、人数や個人の能力だけでなく、知識を引き継ぎ、改善の時間を確保する体制まで考える必要があると感じる。 誰かの頑張りで復旧していると、運用は回っているように見える。その裏で何が後回しになっているかも見たい。作ってリリースする成果と同じように、安定して動かし続けるための仕事を評価できているか。AIで作れるものが増えるなら、なおさら運用まで含めて仕事を設計することが大事だと思う。

『ソフトウェア開発者は、エージェントを作る人になっていく』 AIエージェントを使ってコードを書く。その次に来るのは、自社の製品で働くエージェントを設計する仕事だ。LeadDevの記事では、Agentic AI Foundation（AAIF）の幹部がこの変化を予測し、行動の制御や問題の調査まで担える開発者を増やす必要があると述べている。 AIを使いこなすことと、AIに仕事を任せられるように設計することは、違う能力だと思う。何を任せ、何を制限し、失敗したときにどう調べるか。コードを書く速度だけでなく、こうした設計をチームで学ぶことが大事になりそうだ。 以下、詳細です。 ・エージェントを作るためのスキル 同じ入力でも結果が変わりうるシステムを扱い、できることとできないことを制御する。行動を記録し、問題が起きたら実行履歴を追って原因を調べる。記事は、エージェントの利用経験だけでは身につかないスキルに目を向けている。 ・MCPの普及と社内ルール MCP（Model Context Protocol）は、AIを外部のデータやツールにつなぐための共通規格だ。AAIFによると、ChatGPT利用者によるMCPのツール呼び出しは、2026年8月に同年1月の98倍に達した。ただし、呼び出し数の増加だけでは、信頼性や安全性までは分からない。 ・接続した後の管理 ネットで見つけたMCPサーバーを導入するだけでは、安全な運用にはならないと記事は指摘する。組織としてMCPサーバーをどう管理し、どんな制御を加えるかを決める必要がある。エージェントの機能追加と、運用のルールづくりを一緒に進める話だ。 ・エージェント同士の連携 企業がエージェントをサービスとして提供するようになると、組織をまたぐデータへのアクセスや仕事の委任が問題になる。記事は、エージェント間の通信を支えるA2A（Agent2Agent）を紹介する。単体のエージェントだけでなく、他社のエージェントとの連携も視野に入れた議論だ。 ・採用する規格の運営も見る 技術的につながるかだけでなく、その規格が安定しているか、中立的な組織が運営しているか、自社の要望を提案できるかも評価する。記事は、エンジニアリングリーダーに、オープンソースや標準化への参加も促している。これは、標準化を推進するAAIF側の立場からの提言でもある。 読んでいて感じるのは、開発者が学ぶ対象も変わるということだ。エージェントにうまく指示を出すだけでなく、権限や記録、他のシステムとの連携まで含めて設計する。それを個人の試行錯誤で終わらせず、チームの知識として共有できるかが気になる。

『なぜコーディングエージェントはこんなに賢くないのか？』 寝る前にAIへ仕事を任せたら、Gitのブランチ名を聞くために2分で止まり、そのまま朝まで待っていた。モデルは賢くなっているのに、作業の進め方や人への確認が足を引っ張る。この記事は、モデルをコードや実行環境につなぐエージェント側の設計を批判している。 これ、人に仕事を任せるときにもよくある話だと思う。作業ができることと、必要な判断をしながら仕事を進められることは違う。AIも、コードを書く能力だけでなく、どこまで自分で決めて、何を相談するかまで含めて考える必要がある。 以下、詳細です。 ・タスクの進行管理 OpenCodeが機能追加を10個のタスクに分けても、並行して進められるものまで順番に実行していたという。Claude Codeでも、テストの待ち時間を使わず、終了後にコミットメッセージの準備を始める例があった。タスクを分けるだけでは、待ち時間や依存関係を踏まえた進行管理にはならない。 ・モデルへの仕事の割り振り 単純作業には安く速いモデル、難しい判断には高性能なモデルを使いたい。しかし、著者の経験では、その切り替えを人が細かく管理する必要がある。割り振る手間を避けるため、結局すべてを高性能なモデルへ任せてしまう。 ・人が理解できる計画 細かな設計判断が脈絡なく並び、全体像をつかめない計画が出てくる。著者は読むのが苦痛になり、確認せず実装へ進ませるようになったという。人にレビューしてもらうなら、概要から詳細へ説明し、画面案や図も使って理解を助けてほしいという指摘だ。 ・確認で止まる条件と、自分の機能の把握 ブランチ名のような小さな判断でも止まり、人の回答を待ち続ける。また、自分自身の使い方を聞かれても、動作中のバージョンと一致するか分からない情報をネットで探す。著者は、不在時にも作業を進める機能や、自分の機能を把握するための情報を求めている。 ・アクセスを制限する実行環境 著者は、読まないよう指示した秘密情報をエージェントに読み取られ、モデル提供元へ送られた経験を報告している。求めているのは、文章でのお願いに頼らず、OSの機能でファイルや通信へのアクセスを制限すること。自分でも隔離環境を作り、触れられる範囲を限定している。 ・標準機能としての使いやすさ 大量のSkillsや複雑な設定を追加すれば解決する、という話ではない。著者が問うのは、導入した状態でどこまで安心して任せられるかだ。派手なデモやベンチマークが優先され、開発者の時間や安全性への投資が不足しているのではないか、と仮説を述べている。 特に気になったのは、計画の読みにくさが、人が確認を省く原因になっている点だ。「人が確認する」という工程を置いても、説明が分かりにくかったり、細かな確認が多すぎたりすれば、確認する側が疲れてしまう。 この記事は一人の開発者の経験と提言であり、各ツールの性能を体系的に比較したものではない。それでも、生成したコードの質に加えて、人が理解し、判断し、任せるためにどれだけ手間がかかるかを見る視点は大事だと思う。

10/23(金)に東京・大崎で開催する「HoloLab Conference 2026」は多くのお申込みをいただき、一般のお申込みは週明けで閉じる見込みです。 ご参加をお考えの方は早めにお申し込みください！ ご招待につきましては直前まで対応しておりますので、お近くのホロラボメンバーにお声がけください。 #HoloConf26#

社長の皆さん、 #RSGT2027# のプロポーザルの提出・投票期限は2026/10/13(火) 17:00までですよー！ 期限直前の10/11（日）21:00からプロポーザルわいわい会をいつも通り勝手にやろうと思います。せっかくなのでそこまでにプロポーザルを書いて持ち込んでくれる方・いろんな人のプロポーザルを肴にわいわいしたい方・ギャザリング前からお祭りを味わいたい方はぜひふらっと遊びに来てください。 初心者大歓迎です。

インタビューしていただきました！ スモールチーム制と「失敗を成功に変える」マインドがエンジニアの価値を高める。ホロラボ社の執行役員・及部氏が解説 - アンドエンジニア - エンジニアのこと、エンジニアから。

10/11（日）21:00からRSGT2027のプロポーザルわいわい会をやります！ 10/13（火）17:00締め切りなので、わいわい会までにプロポーザルを書いて持ち込んだり、わいわい会でいろんなプロポーザルを見てギャザリング前から楽しみましょう。初心者大歓迎です。 #RSGT2027#

「仕事の推進力」という能力？ふるまい？は漠然と存在するなーと思っている。 推進力があると、 ・実現しやすくなる ・良い結果も悪い結果も早くわかるのでリズムができる ・「待ち」にならないので、チーム全体のテンションが保たれやすい などいいことは思いつくけど、悪いことは思いつかない。仕事が蓄積するとかは推進力の問題ではなくて優先順位づけの問題だし。

インタビューしていただきました！ スモールチーム制と「失敗を成功に変える」マインドがエンジニアの価値を高める。ホロラボ社の執行役員・及部氏が解説 - アンドエンジニア - エンジニアのこと、エンジニアから。

10/11（日）21:00からRSGT2027のプロポーザルわいわい会をやります！ 10/13（火）17:00締め切りなので、わいわい会までにプロポーザルを書いて持ち込んだり、わいわい会でいろんなプロポーザルを見てギャザリング前から楽しみましょう。初心者大歓迎です。 #RSGT2027#

技術もビジネスもチームも組織もマネジメントもプロセスも全部大事だよってことはAI以前も以後も変わらないんだけど、とんでもない新しい変化の前でわちゃわちゃしているだけなんだよね。 でも混乱を期にいっちょいいこと言ってやろうっていうハリボテインフルエンサーなのか、そのわちゃわちゃを楽しんで本気で問題解決しようとしているソルジャーなのかを見極めるようにしている。

「AIを管理するための6つの指針」 AIに仕事を任せるには、手順だけでなく「何を優先し、どこまで決めてよくて、いつ人に相談するか」まで設計する必要がある。IEEE Spectrumの寄稿で紹介されている6つの指針が、人に仕事を任せる話にも通じていて面白い。 ① 人を情報の中継役にしない データの転記や受け渡しをAIに任せ、人は重要な判断に時間を使う。 ② 判断の原則と優先順位を決める 細かな手順だけでなく、何を守り、何を優先し、誰が決めるかを明確にする。 ③ 企業文化を具体的な指示にする 抽象的な価値観を、守るべき制約・判断基準・業務手順に落とし込む。 ④ 任せる範囲を段階的に調整する 全自動か全件確認かの二択にせず、判断の確かさに応じて人へ引き継ぐ仕組みをつくる。 ⑤ 判断に必要な背景情報をつなぐ 契約、予算、顧客対応の履歴などを結びつけ、状況を踏まえて判断できるようにする。 ⑥ 人は例外に集中する 定型処理を任せ、曖昧な状況や前例のない問題、影響の大きい判断に関わる。 Lowe’sでAI戦略を率いるSravan Vadigepalliによる提言。読んでいて感じるのは、AIにどれだけ作業させられるかと同じくらい、任せるための仕事の設計が問われるということ。組織の中で暗黙に共有してきた判断基準を、言葉にする機会にもなりそうです。

「Scrum Day India 2026レポート：自律型AIエージェント時代のスクラムチーム」 AIが実装を速くしても、人の確認が追いつかなければ仕事は早く終わらない。Scrum Day Indiaで繰り返し語られたのは、エージェントの働き方に合わせて、責任の所在、レビュー、仕事とコストの見える化を設計し直す必要性だった。 ここまでは世界中で似たような話にあふれているので聞き飽き…再現性が高い話なんだろうな。だからはやくこの問いに向き合う段階まで持ってきて、その上でどうするのかを試行錯誤した知見を共有し合える場ができてくると嬉しい。 以下、詳細です。 ・仕事を任せても、成果への責任は人に残る 記事を貫くのは、エージェントは作業を担えても、成果への責任までは引き受けられないという考え方です。誰が出力を確認し、チームの成果物として受け入れるかを明確にする。完成と判断する品質基準である「完成の定義」も、AIが作る仕事を踏まえて見直す提案です。 ・速くなった工程の先に、次の制約が現れる Chetan Aroraは、個人の生産性向上を事業成果につなげるには、開発全体の仕組みを変える必要があると指摘。実装が速くなると、課題探索や計画、テスト、リリースが制約になります。生成された成果物を十分に確認しないまま承認する「レビュー負債」も、記事が強調するリスクです。 ・計画と可視化に、エージェントの仕事を組み込む Sainiは、スプリントプランニングで人とAIへの仕事の割り当てを明示し、プロダクトゴールをエージェントにも共有することを提案しています。スプリントバックログにはAIの作業や「人のレビュー待ち」を見える形で置く。処理量だけでなく、利用コストや失敗、介入の必要性も検査の対象にします。 ・複数エージェントの途中に、人の判断を置く実践 Harmeet Kaur BhasinとSantosh Bhushanは、仕様づくりを支援する仕組みと、Jiraのチケットからテスト済みのPRを作る仕組みを紹介。後者では6種類の専門エージェントを使い、途中に3か所の人による承認を設けています。各承認段階から、人のフィードバックを受けてやり直せる構成です。 ・事務作業が減った時間を、何に使うかが問われる Shalini Khannaは、追跡や文書化をAIに任せた先で、スクラムマスターがコーチングやリスクへの対応、仕事の流れの改善に注力する姿を示しています。記事の最後にも、AIが取り除いた仕事と、その時間の使い道を問う振り返りの質問が置かれています。 この記事を読んで考えたいのは、AI導入後も以前と同じ計画やボード、確認方法を使い続けてよいのか、ということです。実装量だけ増えて、人の確認待ちが積み上がるなら、チームとして扱える仕事の量は別に考える必要があります。 次の振り返りで「AIによって、ボトルネックはどこへ移ったか」を話してみるだけでも、改善の対象が変わりそうです。速くなった部分をさらに速くすることに加えて、その先で仕事が止まる理由まで見ていきたいと思いました。

「スクラムにおける主体性の役割：自分たちで決められない『自己管理』は偽りである」 「自分たちで考えて自律的に動いてほしい」と言いながら、担当も進め方も外から決めていないか。成果への責任を求めるなら、その成果に向けて判断し、行動できる余地も必要になる。自己管理を、チームの心構えだけで終わらせないための話だった。 Martin Hinshelwoodによる、スクラムとAgencyについての記事。ここでいうAgencyは、意欲や積極性だけでなく、責任を持つ成果に向けて意思決定し、行動できる力を指す。 以下、詳細です。 ・責任を持つには、結果に働きかけられる必要がある 筆者は、判断する権限を取り上げたまま責任だけ残すと、責任が失敗を押しつける仕組みになると指摘します。何を担うかと、そのために何を決められるかは、セットで考える必要があります。 ・イベントを開いても、自己管理にはならない 上からスプリントゴールを指定し、マネージャーが個人に仕事を割り振る。こうした状態にデイリースクラムを加えても、チームが自ら仕事を進めているとは言えない、と論じています。 ・変えられないなら、振り返りも形骸化する 改善点を見つけても、チームに変更する力がなければ次につながりません。筆者は、自己管理を成立させる条件が欠けることで、イベントが報告や儀式へ変わってしまうと捉えています。 ・スクラムマスターも、進行役だけでは足りない 会議の設定や議事録にとどまらず、チームとリーダーに自己管理を伝え、組織の障害に働きかけることを求めています。組織の抵抗でそれができないなら、その制約自体を明らかにすべきだという主張です。 この記事から考えたいのは、「もっと主体的に」という言葉を使う前に、相手が実際に何を決められる状態なのかを確認することです。提案することは許されても、毎回判断を覆されるなら、自分で考えて動く意味を見いだしにくくなりそうです。 たとえば、次の振り返りで出た改善案について、チームだけで試せるものと、外部の判断が必要なものを分けてみる。そこで見える制約を話し合う方が、「自己管理できているか」という抽象的な議論より、具体的な変化につながるのではないかと感じました。

「最近のテック業界はなぜこんなに憂鬱なのか？」という記事。知識労働者が感じている違和感は、単純にAIによって仕事が奪われる不安だけではなく、自分たちの仕事に本当に意味があったのかに気づき始めたことではないかという考察。 AI疲れはまさにこれだと思っていて、ただ効率だけの話をせずに、人間の非効率なプロセスに焦点を当てたほうがよいと最近思い始めていたのでわかる。 以下、詳細です。 ・多くの知識労働者が、陶芸、絵画、編み物、農業など「自分の手で何かをすること」に惹かれ始めている ・背景にあるのは、単なるAIによる失業への不安ではなく、「自分の仕事には何の意味があるのか？」という実存的な問い ・これまで高給の知識労働は、仕事に自己実現・コミュニティ・人生の意味を求める「Workism（仕事主義）」によって支えられてきた ・一方で実際の仕事には、誰も読まない資料、実現しないプロジェクト、求められていない機能など、価値が見えづらいものも多い ・それでも人間自身が考え、議論し、作ることで、「自分たちの仕事」という感覚を持つことができていた ・AIエージェントは、その最後に残っていた人間的な部分まで代替し始めている ・資料作成、調査、企画、戦略立案までAIに任せ、人間が「AIのアウトプットを確認する人」になると、仕事との距離はさらに広がる ・経営者から見ると「少人数＋大量のAIエージェント」は効率的。しかし、そこには重要なものが抜け落ちる可能性がある ・それが「Messy Middle」。人間同士で議論し、迷い、試行錯誤し、一緒に問題を解決する非効率なプロセス ・仕事の価値はアウトプットだけではない。同僚との関係、議論、探索、創造する体験そのものが、人が仕事を続ける理由にもなっている ・特に「成果」より「体験」に価値を感じる人にとって、AIによる徹底的な効率化は仕事の魅力そのものを破壊する可能性がある ・だからAI時代に必要なのは、すべてを自動化することではなく、「あえて人間がやる仕事」を意識的に残すことかもしれない