GitHub Universe2026現地レポート: Day1, Day2現地セッションレポート
サンフランシスコで開催されたGitHub Universe 2026から、Day1, Day2で私が参加したセッションの内容をお届けします。
現地オンリーのセッションも含まれます。長大ですがどうぞお楽しみください。
!
各セッションの内容は、私が現地で聞いた内容をベースに日本語にしています。
一部意訳も含みます。
Humans set direction. Agents close the loop.
スピーカー：
Mario Rodriguez, Chief Product Officer@GitHub
Evan Boyle, Partner Director of Engineering@GitHub
GitHubをエージェントネイティブなプラットフォームへ
GitHubはエージェントネイティブなプラットフォームを目指している。エージェントによって創造性を高め、開発者がフロー状態を保てるようにすることが狙いだ。それが、我々が提唱するThe Agent-Native System Engineeringだ。
価値を測る基準は、使ったトークンの量ではない。エージェントによってどれだけのアウトカムを生み出せたかで測るべきである。
Copilot AppとCopilot Projects
Copilot Appでは画像生成もできるようになった。また、KeynoteではCopilot Projectsが発表した。これにより、複数のリポジトリのコンテキストをエージェントに与え、プロジェクトにまたがる作業を進めることができるようになる。
Copilot Skills: 'Lever'でCIを改善する
Copilot Skillsを使って「多くの人がやりたくない仕事」をエージェントに任せよう。その一例として、Copilot Skillsをフィードバックループの構築や安全な委任、繰り返し作業の自動化に活用するOSSの'Lever'を使ってCIの高速化の例を紹介しよう。
CIが遅いという課題に対し、まずはどこがボトルネックなのかを分析する。改善の目標や指標をコード変更前に定め、変更後の結果を比較できるようにする。PRをより早くGreenにすることをアウトカムとし、pushから必要なCIジョブがすべて成功するまでの時間を指標にしていた。CIにはノイズがあるため、同じコミットで比較実行し、効果が確認できた改善だけを残す。
Leverは、改善案をひとつずつ試すのではなく、複数のエージェントにアイデアを並列に検証させる。約20個の改善案を実際のCIで比較し、効果のない案は採用せず、結果が出たものだけを取り入れる進め方だ。
5日間で得られた成果
この取り組みでは、わずか5日間で次の成果が得られた。
135個の大きなcrateを分割し、サイズを約3分の1にした
20件のPull Requestのうち19件をマージした
遅いCIジョブのひとつを約28%高速化した
人間が入力したメッセージは38件。一方、スケジュールされたエージェントは373回実行された。人間が方向を定めたあと、エージェントが試行と検証のループを回す様子が数字にも表れている。
Leverの6つのコマンド
Leverには、作業の目的に応じた6つのコマンドが用意されている。
loop：改善目標と評価指標を定義し、変更前後を比較する
arms：複数のエージェントで改善案を並列に検証する
refactor：巨大なコードを分割・整理する
review：複数モデルでコードをレビューする
shepherd：CIを維持しながら、変更のマージまで支援する
brief：短い指示から、エージェントが自律実行できる計画を作る
LeverはOSSとして公開されている。ソースコードはgithub/leverから確認できる。
エージェントに退屈な仕事を任せる
退屈な仕事はエージェントに任せ、人間は楽しい仕事に取り組もう。CIの改善のように、繰り返し仮説を試し、結果を確認する作業はエージェントが得意とする。一方で、人間は何を改善するのかを決め、成果を評価し、次の方向を示す。
また、新しいことに挑戦したら、ローカルホストの中だけで終わらせず、共有することも大切だ。創造性、コラボレーション、コミュニティ。これが我々が重視していることだ。これはLeverをOSSとして公開していることにもつながっている。
GitHub Copilot and Windows: Bringing local models into the workflow
スピーカー：Ryan Hecht, Product Manager@GitHub
Copilot FusionがKeynoteで紹介された。ここではWindowsのローカルモデルもそのCopilot Fusionのセッションで利用できるということを紹介する。
これにより、GitHubが提供している従来のクラウド上のモデルと、Windows上のローカルモデルを組み合わせて、Copilot Fusionがタスクの内容に応じて使い分けることができるようになる。
まず、OllamaでGemma 4、Nemotron 3.5、Qwen 3.8などのモデルをローカル環境に用意する。Copilotのモデル選択画面からローカルのOllamaエンドポイントを追加すると、Copilot Fusionのセッションで利用するモデルとして選択できる。
選択したモデルはそのセッションでのみ使われ、AutopilotやAssistantのセッション設定は変更しない。用途に応じてローカルモデルとGitHub Copilotのモデルを選び分けられる形だ。
ローカルモデルを既存のCopilotのモデル選択に組み込むことで、タスクや実行環境に合わせてモデルを選ぶ選択肢が広がるだろう。
GitHub Configuration as Code: Scaling org management with Terraform
スピーカー：Yasuhiro Osaki, Software Engineer@SONY
SONYではGitHub EnterpriseのOrgが増えるにつれ、管理のコストが増大した。管理者としてセキュリティリスクを鑑みて、自信を持って全てのユーザーに展開することができなかったため、新機能を無効にすることすらあった。セキュリティを優先すると、生産性を低下させるリスクもあった。
GitHubの管理モデルには、中央集権的な管理にするか、分散的な管理にするかという２つのアプローチがある。両者もメリットとデメリットがある。前者はガバナンスを明確にすることができる一方で、管理者への負担が集中し、管理はブラックボックス化するというデメリットがある。後者（分散的管理アプローチ）の場合、より自由に使うことができるが、GitHubの管理スキルに精通している必要になるし、ガバナンスは断片的になってしまう。
そこで取り組んだのが、Terraformを使って全てのGitHubの管理をコードとして管理することである。
それにより、全てのGitHub Enterprise 管理に関する変更は、PRを経てマージされ、透明性を持って管理される。
しかし全てのユーザーがTerraformを書く必要はない。ユーザーはissue templateからテンプレートを選択して変更リクエストを要求し、Copilot Cloud Agentをアサインする。その後、PR上でtf lint、terraform fmt、terraform validate、terraform plan、Copilot Code Reviewなどの自動チェックを経て、Terraformが更新される。チェックに通った変更はterraform applyでデプロイされる。
また、シークレットの管理も重要である。シークレットの管理にもTerraformを活用した。シークレットはハードコードをすべきではない。GitHub CLIとTerraformを活用し、GitHub Secretに登録されるようにした。
これにより、透明性と中央集権的管理を両立した。それにより以前よりも自信を持ってGitHubを管理することができるようになった。私のアドバイスは、全ての設定を一度にコード化しないことだ。
本番運用では、Membershipとリポジトリに関する変更リクエストが特に多かった。開発者が10人から150人以上に増えてもガバナンスを維持し、GitHub Copilotを使ってコードの作成やレビューも行っている。設定をオープンにすることで、オーナー、開発者、AIが一緒に変更に取り組めるようになった。3年間で、GitHubの設定を変更したPull Requestは810件になる。
大崎さんの登壇資料はこちらで公開されています！
speakerdeck.com
Resolve your security findings faster with GitHub Copilot
スピーカー：Carlin Cherry, Senior Product Manager@GitHub / Jon Janego, Senior Product Manager@GitHub
Dependabotは、サプライチェーンリスクに起因するセキュリティ脆弱性を発見してくれる。しかし、発見したあと、この大量のアラートをどうするか？ということが問題になる。ここでAgentic Autofixを活用することができる。エージェントにセキュリティインシデントへの対応を手伝ってもらうのだ。
Agentic AutofixはCloud Agentと同様、GitHub Actionsによって実行される。セッションログから、どのように脆弱性を修正したのかを追跡することができ、途中で追加の指示を追加することも可能だ。途中で追加した指示はMemoryに蓄積されるため、プロジェクト固有の振る舞いとして記憶した上で動く。
セキュリティリスクの修正にCopilotを使うようになる前と後では、修正のスピードが大幅に向上した。Code scanning alertの修正は45%、Dependabotのアラートの修正は75%修正速度が向上したという。
番外編: 会場のようす(1)
ちなみにこのセッションはDemos & Donutsというスペースで行われていました。文字通りドーナツを食べながらデモを楽しめるスペースです。とてもアメリカっぽいドーナツが山盛りになっていました。
How Microsoft AI builds coding models optimized for GitHub Copilot
スピーカー：Julia Kasper, Product Manager@Microsoft / Yanan Cai, Principal Product Manager@Microsoft
Microsoftは先日のBuildからMAIというMicrosoft独自のモデルを発表した。Microsoftにとって独自モデルを作るベネフィットは、GitHub Copilotのリアルなワークフローに適合するようにチューニングした上で、1つのシステム上で動くモデルを設計できることだ。
ポイントは3つだ。
実際のAgentic Harnessやツールを使ってモデルを学習・評価する
品質、レイテンシ、トークン効率、推論コストを総合的に最適化する
開発者の利用データをもとにモデルと製品を継続改善する
単に高性能なモデルを採用するのではなく、開発体験全体を最適化するという思想が元になっている。
本番環境での実験前に、公開ベンチマークとGitHub独自の内部ベンチマークでオフライン評価を行う。タスクの成功率、Pass Rate、解決までの時間、推論の詳細度、レイテンシなどを測定する。単なるモデルの性能比較ではなく、実際の開発ワークフローでの品質と効率を重視している。
GitHub Copilotのモデル改善では、公開ベンチマークだけでなく、実際の製品環境でのA/Bテストを重視する。5月以降、1〜2週間ごとに新しいモデル候補を検証し、改善を続けている。
成果の例として、最初のトークンまでの時間を10%短縮、トークン間の待ち時間を25%短縮、エラー率を13%減少、途中キャンセル率を10%減少させたことが紹介された。
我々にとってのモデルの成功は、単なるベンチマークのスコアだけではない。いかにリアルな開発環境のワークフローに適合し、開発体験を向上させたかということを重要視している。
How GitHub Secures Open Source
スピーカー：Bas Alberts, Principal Security Researcher@GitHub / Xavier René-Corail, Sr. Dir, Security Research@GitHub
OSSは今や世界を動かしている。しかし、その安全を支えるメンテナーの負担は大きい。Log4jのメンテナーであるChristian Grobmeierは「誰もあなたの様子を確認しに来るわけではない。みんなが気にかけているのはプロジェクトの状況だ」という言葉を残している。これはOSSメンテナーが直面する現実を端的に表している。
しかしOSSの持続可能性を考えるうえで、我々GitHubはプロジェクトの健全性だけでなく、それを支える人間への配慮も重要であると考えている。
セキュリティを持続可能にするには、メンテナー個人にさらなる努力を求めるのではなく、負担を減らし、コミュニティ全体で支える仕組みが必要だ。そのための原則が次の3つだ。
Make it Easy：作業そのものを減らし、安全な方法をデフォルトにする
Make it Delicious：普段の開発や学習の流れにセキュリティを組み込む
Make it Social：活動時間に資金を提供し、専門知識と責任を共有する
セキュリティの専門知識を再利用する
従来、攻撃者やセキュリティ専門家とOSSメンテナーの間には、専門知識へのアクセス格差があった。最先端のAIモデルによって、脆弱性を見つけるハードルは下がりつつある。一方で、見つけた脆弱性が実際に悪用可能かどうかを証明するには、依然として専門的な検証が必要だ。
そこで、専門家が得た知見を一度きりの対応で終わらせず、再利用できる形にしてOSS全体へ広げる。紹介された流れは、脆弱性をFindし、再利用できる検出パターンをExtractし、CodeQLクエリやLLMプロンプトとしてCodifyし、他のプロジェクトへScaleするというものだ。
GitHub Security LabのTaskflow Agentは、セキュリティ専門家の監査ノウハウを、再利用可能なプロンプトと構造化されたTaskflowに変換する。各OSSプロジェクトでエージェントを実行し、監査結果をレビューして再現性を検証することで、専門家の知見をプロジェクト間で活用できる。
発見だけでなく修正までつなげる
脆弱性を検出しても、修正につながらなければバックログが増えるだけだ。GitHub Copilot Autofixは、CodeQLが検出した脆弱性に対する修正案を生成する。GitHubが公開ベータ期間に収集したデータでは、修正をコミットするまでの時間の中央値が約3倍速くなったという。これは正しさを保証する数字ではなく、修正までの速度に関する結果だ。
リリース経路を守る
リリース経路そのものが攻撃経路になることもある。2025年9月のShai-Hulud攻撃では、npmメンテナーのアカウントが侵害され、500以上の悪意あるパッケージが削除された。安全なリリース経路を標準化することが重要になる。
紹介された対策では、信頼できないコードにはリリース権限を与えず、保存されたトークンではなくワークフローに紐づくOIDCで公開する。また、段階的な公開プロセスを使い、安全なリリースを仕組みとして実現する。
GitHub CLIのgh secureを使うと、リポジトリのセキュリティ設定を確認し、適用を支援できる。たとえば、現在の状態を確認するにはgh secure status、変更を適用する前にプレビューするにはgh secure --dry-runを使う。Branch Protection、Secret Scanning、Dependabot、Code Scanningなどの設定を扱える。
GitHub Security Labによる脆弱性の責任ある開示の成果として、報告した脆弱性の95%が最終的に修正されている。脆弱性を発見・報告するだけでなく、実際の修正につなげることが重要。この数字は、OSSメンテナーとの信頼関係を表しており、一件一件の報告を通じて築かれきた。
OSSの安全をエコシステム全体で支える
GitHub Secure Open Source Fundは、OSSメンテナーに資金、専門知識、セキュリティ支援を提供するプログラムだ。紹介された実績では、216のプロジェクトがセキュリティを改善し、4,000件以上の脆弱性が修正された。メンテナーの活動を支援することが、多くの利用者を守ることにつながる。
役に立つことを1つやれ。新たな作業の山を作ってはいけない。
OSSのセキュリティを個人の善意だけに依存させず、エコシステム全体で支えていく必要がある。
17 agents, one SDLC: How Levi Strauss reimagined development on GitHub
スピーカー：Jenny Patchen, Sr. Director, Shared Platforms & Services@Levi Strauss & Co.
Levi Strauss & Co.が、17のエージェントを活用してSDLCを改革した事例。最初に取り組んだのはエージェントを作ることではなかった。まず成功の定義を決め、品質を高め、あとから展開できるように設計と観測の方法を標準化した。
エージェントを作る前にワークフローを設計する
最初の数日は、品質エンジニアを含め開発プロセスに関わるエンジニアや各ロールのメンバーが集まり、数日かけてワークフローを設計した。繰り返すが、先にエージェントを作らず、まずプロセスに関わる人たちで仕事の流れを整理することが重要だ。
設計されたワークフローでは、人間がユーザーストーリーを定義し、回帰テストや品質を管理する。エージェントは実行を担い、判断は人間が行う。エージェントにすべてを任せるのではなく、人とエージェントそれぞれの役割を明確にしている。
たとえばRequirement Agentは、機能追加リクエストを受け取ると、依頼内容やチケット、仕様テンプレートをもとにテスト可能な要件を作成する。不明点があれば人に確認し、チーム全体が実装に使える明確な仕様を出力する。最後に人間が仕様を承認する。
17の専門エージェントを支える基盤
次に、エージェントを動かすためのプラットフォームを再構築した。開発者からのリクエストを1つのOrchestration Agentが振り分け、17の専門エージェントがそれぞれの役割を担う。GitHub.com、Copilot CLI、VS Codeなど開発者が使う場所から依頼でき、JiraやNew Relic、Playwrightなどのツールや情報とも連携する。
すべてのリポジトリは、最初からagent-readyな状態で作成される。スターターキットやCI/CD定義、エージェント向けの設定と指示を用意し、PRごとに依存関係やテスト、カバレッジなどのCIゲートを実行する。CIに失敗した場合はAgentic AutofixがCopilotに修正を依頼し、修正後に再検証する。
さらに社内マーケットプレイスを用意し、エンジニアがエージェントやプラグインをセルフサービスで導入できるようにした。登壇時点の紹介では、24のエージェント、19のスキル、15のMCPサーバーが登録され、利用するエンジニアが評価し、VS CodeやGitHubで共有できる仕組みになっている。
継続できる導入にする
この取り組みを一時的な成功で終わらせず、継続可能なものにするため、AIエンジニアを含むチームを組織した。導入前の事前資料、実際のコードを使ったハンズオントレーニング、開発者向けのオフィスアワーなどを通じて、利用者のサポートにも取り組んだ。
運用上の原則も定めている。人間は判断を担い、曖昧さのある仕事に時間を使う。コンテキストはチャットではなく、リポジトリやチケットなどエージェントが確認できる場所に置く。エージェントにも人間と同じ品質ゲートを適用し、すべてのエージェントの動作と人間による上書きを記録して監査可能にする。
その結果、スループットは51%、PR合格率は54%向上し、AIの支援を受けて作成されたPRの割合は26%から69%に増加した。
導入から得られた学び
1つのブランチ上で複数の作業を並列に進める方法はうまくいかず、PR内では逐次実行する方が有効だった。また、要件の曖昧さは設計の早い段階で明らかになった。最初のワークショップには大きな需要があり、現在は展開を拡大している。次の開発チームは、より迅速に導入できる見込み。
重要なのは、エージェントの数を増やすことだけではない。タスクの分け方と、人間が判断しエージェントが実行する協働プロセスを設計することだ。1873年にワークウェアを再創造したLevi Straussが、今年再創造したのはソフトウェア開発だった。
Treat your AI context as infrastructure
スピーカー：Christopher Harrison, Senior Developer Advocate@GitHub
Copilotに一度指示するだけで素晴らしいアプリを作れる場面はある。しかし、エンタープライズの開発では、既存のアーキテクチャやテスト・ドキュメントのルール、過去の意思決定、タスク間の関係を考慮しなければならない。リポジトリには、アーキテクチャ、規約、タスクに関係する情報が蓄積されている。大きなリポジトリを丸ごと渡すのではなく、Copilotに必要な理解を与えることが重要だ。
仕事に合ったコンテキストとツールを選ぶ
Copilot Code Reviewに多くの改善ツールを追加した結果、コストが上がり、有益な指摘が減った事例が紹介された。トレースを確認し、差分から始めて調査範囲を絞り、根拠を限定するように調整したところ、平均的な本番レビューコストは約20%低下した。同じプロンプトやツールの組み合わせが、異なる仕事でも同じ成果を生むとは限らない。目的に合ったツールを選び、結果を測る必要がある。
プロジェクト共通の規約や標準はinstructionsに書き、単発タスクへの依頼とは分ける。専門的なガイダンスは、対象ファイルに合わせてスコープを限定する。そうすることで、関係のないコンテキストを必要以上に読み込まずに済む。
繰り返し実行する手順はSkillsにまとめる。いつ使うかというトリガーを具体的にし、必要なチェックを実行させ、完了できなかった場合には証跡を残す。特定の役割に集中させたい場合はcustom agentを使い、利用可能なツールも必要なものに絞る。
HooksとMCP Serverも用途が異なる。Hooksはイベントをきっかけに処理を自動実行する仕組みであり、MCPは外部のツール、データ、サービスへの接続に使う。たとえば編集後にフォーマッターを実行する処理はHook、外部情報の取得やIssue作成、ブラウザー操作などはMCPが担う。
MCP Serverに接続できることは、その操作が認可されていることを意味しない。アクセス権限、承認、ポリシーを適用する必要がある。また、SkillとMCPはどちらか一方で置き換えるものではない。手順をSkillに書く一方で、外部データへの効率的なアクセスや操作にはMCPを使う。
組織のコンテキストをエージェントに届ける
たとえば本番環境で障害が起きたとき、コードはリポジトリにあっても、実際に稼働しているリビジョン、サービスオーナー、Runbookの情報は別の場所にある。Custom MCP Serverを使って、サービスカタログや本番デプロイ情報を読み取り専用でCopilotに提供すれば、開発者は別々のポータルを探し回らずに調査を始められる。
複数のエージェントで1つのタスクに取り組む例も紹介された。Feature Build Agentが変更を実装し、QA Agentが動作や回帰を検証し、Accessibility Specialistがラベルやフォーカス、キーボード操作を確認する。それぞれが適切なInstructions、Skills、認可されたツールを使い、調査結果と根拠を返す。作業範囲を限定し、成果を証拠とともに返し、タスク全体のオーナーは一人に保つ。
イベントやスケジュールをトリガーにした共有Automationを使えば、チームのコンテキストをもとに反復可能な作業を行い、レビュー可能な成果物を残せる。トリガー、使うツール、プロンプトはチームが管理する。
一方、MCPやプラグインを組織で安全に使うにはガバナンスが欠かせない。Enterprise managed settingsを使えば、利用を許可するMCP Serverを制御し、プラグインの承認やブロック、インストール元の制限などを組織レベルで適用できる。
コンテキストを育て、評価する
Copilotはツールにすぎず、ツールを渡すだけでは定着しない。教育に投資し、利用している開発者と話し、どこで失敗するかを知ることが重要だ。テレメトリーや評価だけでは分からない摩擦を、アンケートや会話から把握し、共有コンテキストの改善につなげる。
GitHub CopilotのランタイムをTypeScript/Node.jsからRustへ移行した事例では、CodingやReviewのSkillを整備して再利用した。さらにEvalsで期待する結果を定義し、検証、実行、評価を繰り返した。コードを生成する仕組みそのものを改善し、失敗から学んでInstructionsや評価ケースを強化する考え方だ。
最初から大規模な仕組みを作る必要はない。まずは一つのリポジトリと、繰り返し発生するタスクや摩擦を選ぶ。Copilotに既存のコードやドキュメントをもとにInstructionsの案を作らせ、レビューして実際の作業で試す。有効なガイダンスにはオーナーを割り当て、チームのフィードバックを受けて改善する。必要になった段階でSkillsや専門エージェント、ツールを加えていく。
番外編：会場のようす（２）
会場には「Wellness Lounge」というリラックスルームがありました。セッションの合間にゆっくり休憩できる、マインドフルな雰囲気のスペースです。薄暗い空間に水のせせらぎの音が響いていて、とても落ち着きました。
会場は海のすぐそばにあり、建物の近くにはカモメが来ていました。日本で見かけるカモメより少し大きめで、もふもふしていてかわいかったです。
Mentions
Agent 不好用，多半不是模型笨，是你沒給它一把尺。 GitHub 官方剛放出 github/lever，一組 Copilot 技能。最該抄的是 /lever loop：先逼你寫清楚量什麼、怎麼量、多少才算贏，再讓 agent 磨。 自主權分 L0 到 L5，官方建議從 L2 起步。 不用 Copilot，思路也能搬走。 github/lever
GitHub Universe2026現地レポート: Day1, Day2現地セッションレポート サンフランシスコで開催されたGitHub Universe 2026から、Day1, Day2で私が参加したセッションの内容をお届けします。 現地オンリーのセッションも含まれます。長大ですがどうぞお楽しみください。 ! 各セッションの内容は、私が現地で聞いた内容をベースに日本語にしています。 一部意訳も含みます。 Humans set direction. Agents close the loop. スピーカー： Mario Rodriguez, Chief Product Officer@GitHub Evan Boyle, Partner Director of Engineering@GitHub GitHubをエージェントネイティブなプラットフォームへ GitHubはエージェントネイティブなプラットフォームを目指している。エージェントによって創造性を高め、開発者がフロー状態を保てるようにすることが狙いだ。それが、我々が提唱するThe Agent-Native System Engineeringだ。 価値を測る基準は、使ったトークンの量ではない。エージェントによってどれだけのアウトカムを生み出せたかで測るべきである。 Copilot AppとCopilot Projects Copilot Appでは画像生成もできるようになった。また、KeynoteではCopilot Projectsが発表した。これにより、複数のリポジトリのコンテキストをエージェントに与え、プロジェクトにまたがる作業を進めることができるようになる。 Copilot Skills: 'Lever'でCIを改善する Copilot Skillsを使って「多くの人がやりたくない仕事」をエージェントに任せよう。その一例として、Copilot Skillsをフィードバックループの構築や安全な委任、繰り返し作業の自動化に活用するOSSの'Lever'を使ってCIの高速化の例を紹介しよう。 CIが遅いという課題に対し、まずはどこがボトルネックなのかを分析する。改善の目標や指標をコード変更前に定め、変更後の結果を比較できるようにする。PRをより早くGreenにすることをアウトカムとし、pushから必要なCIジョブがすべて成功するまでの時間を指標にしていた。CIにはノイズがあるため、同じコミットで比較実行し、効果が確認できた改善だけを残す。 Leverは、改善案をひとつずつ試すのではなく、複数のエージェントにアイデアを並列に検証させる。約20個の改善案を実際のCIで比較し、効果のない案は採用せず、結果が出たものだけを取り入れる進め方だ。 5日間で得られた成果 この取り組みでは、わずか5日間で次の成果が得られた。 135個の大きなcrateを分割し、サイズを約3分の1にした 20件のPull Requestのうち19件をマージした 遅いCIジョブのひとつを約28%高速化した 人間が入力したメッセージは38件。一方、スケジュールされたエージェントは373回実行された。人間が方向を定めたあと、エージェントが試行と検証のループを回す様子が数字にも表れている。 Leverの6つのコマンド Leverには、作業の目的に応じた6つのコマンドが用意されている。 loop：改善目標と評価指標を定義し、変更前後を比較する arms：複数のエージェントで改善案を並列に検証する refactor：巨大なコードを分割・整理する review：複数モデルでコードをレビューする shepherd：CIを維持しながら、変更のマージまで支援する brief：短い指示から、エージェントが自律実行できる計画を作る LeverはOSSとして公開されている。ソースコードはgithub/leverから確認できる。 エージェントに退屈な仕事を任せる 退屈な仕事はエージェントに任せ、人間は楽しい仕事に取り組もう。CIの改善のように、繰り返し仮説を試し、結果を確認する作業はエージェントが得意とする。一方で、人間は何を改善するのかを決め、成果を評価し、次の方向を示す。 また、新しいことに挑戦したら、ローカルホストの中だけで終わらせず、共有することも大切だ。創造性、コラボレーション、コミュニティ。これが我々が重視していることだ。これはLeverをOSSとして公開していることにもつながっている。 GitHub Copilot and Windows: Bringing local models into the workflow スピーカー：Ryan Hecht, Product Manager@GitHub Copilot FusionがKeynoteで紹介された。ここではWindowsのローカルモデルもそのCopilot Fusionのセッションで利用できるということを紹介する。 これにより、GitHubが提供している従来のクラウド上のモデルと、Windows上のローカルモデルを組み合わせて、Copilot Fusionがタスクの内容に応じて使い分けることができるようになる。 まず、OllamaでGemma 4、Nemotron 3.5、Qwen 3.8などのモデルをローカル環境に用意する。Copilotのモデル選択画面からローカルのOllamaエンドポイントを追加すると、Copilot Fusionのセッションで利用するモデルとして選択できる。 選択したモデルはそのセッションでのみ使われ、AutopilotやAssistantのセッション設定は変更しない。用途に応じてローカルモデルとGitHub Copilotのモデルを選び分けられる形だ。 ローカルモデルを既存のCopilotのモデル選択に組み込むことで、タスクや実行環境に合わせてモデルを選ぶ選択肢が広がるだろう。 GitHub Configuration as Code: Scaling org management with Terraform スピーカー：Yasuhiro Osaki, Software Engineer@SONY SONYではGitHub EnterpriseのOrgが増えるにつれ、管理のコストが増大した。管理者としてセキュリティリスクを鑑みて、自信を持って全てのユーザーに展開することができなかったため、新機能を無効にすることすらあった。セキュリティを優先すると、生産性を低下させるリスクもあった。 GitHubの管理モデルには、中央集権的な管理にするか、分散的な管理にするかという２つのアプローチがある。両者もメリットとデメリットがある。前者はガバナンスを明確にすることができる一方で、管理者への負担が集中し、管理はブラックボックス化するというデメリットがある。後者（分散的管理アプローチ）の場合、より自由に使うことができるが、GitHubの管理スキルに精通している必要になるし、ガバナンスは断片的になってしまう。 そこで取り組んだのが、Terraformを使って全てのGitHubの管理をコードとして管理することである。 それにより、全てのGitHub Enterprise 管理に関する変更は、PRを経てマージされ、透明性を持って管理される。 しかし全てのユーザーがTerraformを書く必要はない。ユーザーはissue templateからテンプレートを選択して変更リクエストを要求し、Copilot Cloud Agentをアサインする。その後、PR上でtf lint、terraform fmt、terraform validate、terraform plan、Copilot Code Reviewなどの自動チェックを経て、Terraformが更新される。チェックに通った変更はterraform applyでデプロイされる。 また、シークレットの管理も重要である。シークレットの管理にもTerraformを活用した。シークレットはハードコードをすべきではない。GitHub CLIとTerraformを活用し、GitHub Secretに登録されるようにした。 これにより、透明性と中央集権的管理を両立した。それにより以前よりも自信を持ってGitHubを管理することができるようになった。私のアドバイスは、全ての設定を一度にコード化しないことだ。 本番運用では、Membershipとリポジトリに関する変更リクエストが特に多かった。開発者が10人から150人以上に増えてもガバナンスを維持し、GitHub Copilotを使ってコードの作成やレビューも行っている。設定をオープンにすることで、オーナー、開発者、AIが一緒に変更に取り組めるようになった。3年間で、GitHubの設定を変更したPull Requestは810件になる。 大崎さんの登壇資料はこちらで公開されています！ speakerdeck.com Resolve your security findings faster with GitHub Copilot スピーカー：Carlin Cherry, Senior Product Manager@GitHub / Jon Janego, Senior Product Manager@GitHub Dependabotは、サプライチェーンリスクに起因するセキュリティ脆弱性を発見してくれる。しかし、発見したあと、この大量のアラートをどうするか？ということが問題になる。ここでAgentic Autofixを活用することができる。エージェントにセキュリティインシデントへの対応を手伝ってもらうのだ。 Agentic AutofixはCloud Agentと同様、GitHub Actionsによって実行される。セッションログから、どのように脆弱性を修正したのかを追跡することができ、途中で追加の指示を追加することも可能だ。途中で追加した指示はMemoryに蓄積されるため、プロジェクト固有の振る舞いとして記憶した上で動く。 セキュリティリスクの修正にCopilotを使うようになる前と後では、修正のスピードが大幅に向上した。Code scanning alertの修正は45%、Dependabotのアラートの修正は75%修正速度が向上したという。 番外編: 会場のようす(1) ちなみにこのセッションはDemos & Donutsというスペースで行われていました。文字通りドーナツを食べながらデモを楽しめるスペースです。とてもアメリカっぽいドーナツが山盛りになっていました。 How Microsoft AI builds coding models optimized for GitHub Copilot スピーカー：Julia Kasper, Product Manager@Microsoft / Yanan Cai, Principal Product Manager@Microsoft Microsoftは先日のBuildからMAIというMicrosoft独自のモデルを発表した。Microsoftにとって独自モデルを作るベネフィットは、GitHub Copilotのリアルなワークフローに適合するようにチューニングした上で、1つのシステム上で動くモデルを設計できることだ。 ポイントは3つだ。 実際のAgentic Harnessやツールを使ってモデルを学習・評価する 品質、レイテンシ、トークン効率、推論コストを総合的に最適化する 開発者の利用データをもとにモデルと製品を継続改善する 単に高性能なモデルを採用するのではなく、開発体験全体を最適化するという思想が元になっている。 本番環境での実験前に、公開ベンチマークとGitHub独自の内部ベンチマークでオフライン評価を行う。タスクの成功率、Pass Rate、解決までの時間、推論の詳細度、レイテンシなどを測定する。単なるモデルの性能比較ではなく、実際の開発ワークフローでの品質と効率を重視している。 GitHub Copilotのモデル改善では、公開ベンチマークだけでなく、実際の製品環境でのA/Bテストを重視する。5月以降、1〜2週間ごとに新しいモデル候補を検証し、改善を続けている。 成果の例として、最初のトークンまでの時間を10%短縮、トークン間の待ち時間を25%短縮、エラー率を13%減少、途中キャンセル率を10%減少させたことが紹介された。 我々にとってのモデルの成功は、単なるベンチマークのスコアだけではない。いかにリアルな開発環境のワークフローに適合し、開発体験を向上させたかということを重要視している。 How GitHub Secures Open Source スピーカー：Bas Alberts, Principal Security Researcher@GitHub / Xavier René-Corail, Sr. Dir, Security Research@GitHub OSSは今や世界を動かしている。しかし、その安全を支えるメンテナーの負担は大きい。Log4jのメンテナーであるChristian Grobmeierは「誰もあなたの様子を確認しに来るわけではない。みんなが気にかけているのはプロジェクトの状況だ」という言葉を残している。これはOSSメンテナーが直面する現実を端的に表している。 しかしOSSの持続可能性を考えるうえで、我々GitHubはプロジェクトの健全性だけでなく、それを支える人間への配慮も重要であると考えている。 セキュリティを持続可能にするには、メンテナー個人にさらなる努力を求めるのではなく、負担を減らし、コミュニティ全体で支える仕組みが必要だ。そのための原則が次の3つだ。 Make it Easy：作業そのものを減らし、安全な方法をデフォルトにする Make it Delicious：普段の開発や学習の流れにセキュリティを組み込む Make it Social：活動時間に資金を提供し、専門知識と責任を共有する セキュリティの専門知識を再利用する 従来、攻撃者やセキュリティ専門家とOSSメンテナーの間には、専門知識へのアクセス格差があった。最先端のAIモデルによって、脆弱性を見つけるハードルは下がりつつある。一方で、見つけた脆弱性が実際に悪用可能かどうかを証明するには、依然として専門的な検証が必要だ。 そこで、専門家が得た知見を一度きりの対応で終わらせず、再利用できる形にしてOSS全体へ広げる。紹介された流れは、脆弱性をFindし、再利用できる検出パターンをExtractし、CodeQLクエリやLLMプロンプトとしてCodifyし、他のプロジェクトへScaleするというものだ。 GitHub Security LabのTaskflow Agentは、セキュリティ専門家の監査ノウハウを、再利用可能なプロンプトと構造化されたTaskflowに変換する。各OSSプロジェクトでエージェントを実行し、監査結果をレビューして再現性を検証することで、専門家の知見をプロジェクト間で活用できる。 発見だけでなく修正までつなげる 脆弱性を検出しても、修正につながらなければバックログが増えるだけだ。GitHub Copilot Autofixは、CodeQLが検出した脆弱性に対する修正案を生成する。GitHubが公開ベータ期間に収集したデータでは、修正をコミットするまでの時間の中央値が約3倍速くなったという。これは正しさを保証する数字ではなく、修正までの速度に関する結果だ。 リリース経路を守る リリース経路そのものが攻撃経路になることもある。2025年9月のShai-Hulud攻撃では、npmメンテナーのアカウントが侵害され、500以上の悪意あるパッケージが削除された。安全なリリース経路を標準化することが重要になる。 紹介された対策では、信頼できないコードにはリリース権限を与えず、保存されたトークンではなくワークフローに紐づくOIDCで公開する。また、段階的な公開プロセスを使い、安全なリリースを仕組みとして実現する。 GitHub CLIのgh secureを使うと、リポジトリのセキュリティ設定を確認し、適用を支援できる。たとえば、現在の状態を確認するにはgh secure status、変更を適用する前にプレビューするにはgh secure --dry-runを使う。Branch Protection、Secret Scanning、Dependabot、Code Scanningなどの設定を扱える。 GitHub Security Labによる脆弱性の責任ある開示の成果として、報告した脆弱性の95%が最終的に修正されている。脆弱性を発見・報告するだけでなく、実際の修正につなげることが重要。この数字は、OSSメンテナーとの信頼関係を表しており、一件一件の報告を通じて築かれきた。 OSSの安全をエコシステム全体で支える GitHub Secure Open Source Fundは、OSSメンテナーに資金、専門知識、セキュリティ支援を提供するプログラムだ。紹介された実績では、216のプロジェクトがセキュリティを改善し、4,000件以上の脆弱性が修正された。メンテナーの活動を支援することが、多くの利用者を守ることにつながる。 役に立つことを1つやれ。新たな作業の山を作ってはいけない。 OSSのセキュリティを個人の善意だけに依存させず、エコシステム全体で支えていく必要がある。 17 agents, one SDLC: How Levi Strauss reimagined development on GitHub スピーカー：Jenny Patchen, Sr. Director, Shared Platforms & Services@Levi Strauss & Co. Levi Strauss & Co.が、17のエージェントを活用してSDLCを改革した事例。最初に取り組んだのはエージェントを作ることではなかった。まず成功の定義を決め、品質を高め、あとから展開できるように設計と観測の方法を標準化した。 エージェントを作る前にワークフローを設計する 最初の数日は、品質エンジニアを含め開発プロセスに関わるエンジニアや各ロールのメンバーが集まり、数日かけてワークフローを設計した。繰り返すが、先にエージェントを作らず、まずプロセスに関わる人たちで仕事の流れを整理することが重要だ。 設計されたワークフローでは、人間がユーザーストーリーを定義し、回帰テストや品質を管理する。エージェントは実行を担い、判断は人間が行う。エージェントにすべてを任せるのではなく、人とエージェントそれぞれの役割を明確にしている。 たとえばRequirement Agentは、機能追加リクエストを受け取ると、依頼内容やチケット、仕様テンプレートをもとにテスト可能な要件を作成する。不明点があれば人に確認し、チーム全体が実装に使える明確な仕様を出力する。最後に人間が仕様を承認する。 17の専門エージェントを支える基盤 次に、エージェントを動かすためのプラットフォームを再構築した。開発者からのリクエストを1つのOrchestration Agentが振り分け、17の専門エージェントがそれぞれの役割を担う。GitHub.com、Copilot CLI、VS Codeなど開発者が使う場所から依頼でき、JiraやNew Relic、Playwrightなどのツールや情報とも連携する。 すべてのリポジトリは、最初からagent-readyな状態で作成される。スターターキットやCI/CD定義、エージェント向けの設定と指示を用意し、PRごとに依存関係やテスト、カバレッジなどのCIゲートを実行する。CIに失敗した場合はAgentic AutofixがCopilotに修正を依頼し、修正後に再検証する。 さらに社内マーケットプレイスを用意し、エンジニアがエージェントやプラグインをセルフサービスで導入できるようにした。登壇時点の紹介では、24のエージェント、19のスキル、15のMCPサーバーが登録され、利用するエンジニアが評価し、VS CodeやGitHubで共有できる仕組みになっている。 継続できる導入にする この取り組みを一時的な成功で終わらせず、継続可能なものにするため、AIエンジニアを含むチームを組織した。導入前の事前資料、実際のコードを使ったハンズオントレーニング、開発者向けのオフィスアワーなどを通じて、利用者のサポートにも取り組んだ。 運用上の原則も定めている。人間は判断を担い、曖昧さのある仕事に時間を使う。コンテキストはチャットではなく、リポジトリやチケットなどエージェントが確認できる場所に置く。エージェントにも人間と同じ品質ゲートを適用し、すべてのエージェントの動作と人間による上書きを記録して監査可能にする。 その結果、スループットは51%、PR合格率は54%向上し、AIの支援を受けて作成されたPRの割合は26%から69%に増加した。 導入から得られた学び 1つのブランチ上で複数の作業を並列に進める方法はうまくいかず、PR内では逐次実行する方が有効だった。また、要件の曖昧さは設計の早い段階で明らかになった。最初のワークショップには大きな需要があり、現在は展開を拡大している。次の開発チームは、より迅速に導入できる見込み。 重要なのは、エージェントの数を増やすことだけではない。タスクの分け方と、人間が判断しエージェントが実行する協働プロセスを設計することだ。1873年にワークウェアを再創造したLevi Straussが、今年再創造したのはソフトウェア開発だった。 Treat your AI context as infrastructure スピーカー：Christopher Harrison, Senior Developer Advocate@GitHub Copilotに一度指示するだけで素晴らしいアプリを作れる場面はある。しかし、エンタープライズの開発では、既存のアーキテクチャやテスト・ドキュメントのルール、過去の意思決定、タスク間の関係を考慮しなければならない。リポジトリには、アーキテクチャ、規約、タスクに関係する情報が蓄積されている。大きなリポジトリを丸ごと渡すのではなく、Copilotに必要な理解を与えることが重要だ。 仕事に合ったコンテキストとツールを選ぶ Copilot Code Reviewに多くの改善ツールを追加した結果、コストが上がり、有益な指摘が減った事例が紹介された。トレースを確認し、差分から始めて調査範囲を絞り、根拠を限定するように調整したところ、平均的な本番レビューコストは約20%低下した。同じプロンプトやツールの組み合わせが、異なる仕事でも同じ成果を生むとは限らない。目的に合ったツールを選び、結果を測る必要がある。 プロジェクト共通の規約や標準はinstructionsに書き、単発タスクへの依頼とは分ける。専門的なガイダンスは、対象ファイルに合わせてスコープを限定する。そうすることで、関係のないコンテキストを必要以上に読み込まずに済む。 繰り返し実行する手順はSkillsにまとめる。いつ使うかというトリガーを具体的にし、必要なチェックを実行させ、完了できなかった場合には証跡を残す。特定の役割に集中させたい場合はcustom agentを使い、利用可能なツールも必要なものに絞る。 HooksとMCP Serverも用途が異なる。Hooksはイベントをきっかけに処理を自動実行する仕組みであり、MCPは外部のツール、データ、サービスへの接続に使う。たとえば編集後にフォーマッターを実行する処理はHook、外部情報の取得やIssue作成、ブラウザー操作などはMCPが担う。 MCP Serverに接続できることは、その操作が認可されていることを意味しない。アクセス権限、承認、ポリシーを適用する必要がある。また、SkillとMCPはどちらか一方で置き換えるものではない。手順をSkillに書く一方で、外部データへの効率的なアクセスや操作にはMCPを使う。 組織のコンテキストをエージェントに届ける たとえば本番環境で障害が起きたとき、コードはリポジトリにあっても、実際に稼働しているリビジョン、サービスオーナー、Runbookの情報は別の場所にある。Custom MCP Serverを使って、サービスカタログや本番デプロイ情報を読み取り専用でCopilotに提供すれば、開発者は別々のポータルを探し回らずに調査を始められる。 複数のエージェントで1つのタスクに取り組む例も紹介された。Feature Build Agentが変更を実装し、QA Agentが動作や回帰を検証し、Accessibility Specialistがラベルやフォーカス、キーボード操作を確認する。それぞれが適切なInstructions、Skills、認可されたツールを使い、調査結果と根拠を返す。作業範囲を限定し、成果を証拠とともに返し、タスク全体のオーナーは一人に保つ。 イベントやスケジュールをトリガーにした共有Automationを使えば、チームのコンテキストをもとに反復可能な作業を行い、レビュー可能な成果物を残せる。トリガー、使うツール、プロンプトはチームが管理する。 一方、MCPやプラグインを組織で安全に使うにはガバナンスが欠かせない。Enterprise managed settingsを使えば、利用を許可するMCP Serverを制御し、プラグインの承認やブロック、インストール元の制限などを組織レベルで適用できる。 コンテキストを育て、評価する Copilotはツールにすぎず、ツールを渡すだけでは定着しない。教育に投資し、利用している開発者と話し、どこで失敗するかを知ることが重要だ。テレメトリーや評価だけでは分からない摩擦を、アンケートや会話から把握し、共有コンテキストの改善につなげる。 GitHub CopilotのランタイムをTypeScript/Node.jsからRustへ移行した事例では、CodingやReviewのSkillを整備して再利用した。さらにEvalsで期待する結果を定義し、検証、実行、評価を繰り返した。コードを生成する仕組みそのものを改善し、失敗から学んでInstructionsや評価ケースを強化する考え方だ。 最初から大規模な仕組みを作る必要はない。まずは一つのリポジトリと、繰り返し発生するタスクや摩擦を選ぶ。Copilotに既存のコードやドキュメントをもとにInstructionsの案を作らせ、レビューして実際の作業で試す。有効なガイダンスにはオーナーを割り当て、チームのフィードバックを受けて改善する。必要になった段階でSkillsや専門エージェント、ツールを加えていく。 番外編：会場のようす（２） 会場には「Wellness Lounge」というリラックスルームがありました。セッションの合間にゆっくり休憩できる、マインドフルな雰囲気のスペースです。薄暗い空間に水のせせらぎの音が響いていて、とても落ち着きました。 会場は海のすぐそばにあり、建物の近くにはカモメが来ていました。日本で見かけるカモメより少し大きめで、もふもふしていてかわいかったです。
lever: Feedback Loops for Coding Agents
github/lever LeverはOSSで、こちらから使用可