AIコーディングツールはコードを素早く生成できますが、速度だけでは最も困難なソフトウェアエンジニアリングの問題は解決しません。開発者は依然として、コンテキストの提供、結果の検証、保守性の保護を行い、リリースされるものに対して責任を負い続ける必要があります。
経験豊富な開発者たちがそのバランスをどのように取っているのかを知るために、Javaの使用経験が10年以上ある3人のJava Championsにお話を伺いました。彼らは、本番環境やオープンソースでGitHub Copilotを使用した具体的な例とともに、AIが生成した出力を信頼性の高いソフトウェアに変えるために実践している方法を共有してくれました。
以下は、彼らが私たちに共有してくれたヒントです。
Vlad Mihalcea
GitHubプロフィール: @vladmihalcea
GitHub Copilotは最近どのように役立っていますか？
Hypersistence UtilsとHypersistence Optimizerの両方で、さまざまな機能の分析、設計、実装に使用しています。
例えば、Optimizerのイベント履歴を提供するWebアプリケーションを開発したいと長い間考えていました。そうすれば、パフォーマンス改善の取り組みがアプリケーションのパフォーマンスにどのように反映されているかを確認できます。AI以前は、開発に数週間かかるため、このタスクは先送りし続けていました。しかしCopilotを使うのは新しいチームメンバーが加わったようなもので、次のバージョンのHypersistence Optimizerに搭載されるアプリをこれを使って作成しました。数週間のところを、このタスクの実装にはわずか2日しかかかりませんでした。
普段はどのように使っていますか？GitHub CopilotをIDEプラグインとして使っていますか、それともGitHub Copilotアプリですか？
ソースコードのレビュー中やデバッグセッション中に実行するのに便利なので、IntelliJ IDEAでGitHub Copilotを使用しています。
コードアシスタントとして非常に有用で、調査の迅速化や、検証が必要な機能のプロトタイプ作成のスピードアップに役立っています。
AIの目的は私を完全に置き換えることではなく、生産性を向上させることなので、AIが生成する計画やコードは今でもレビューしています。AIは多くの状況で正しい答えを提供してくれますが、満足のいく応答が得られず、私の介入が必要な場合もあります。
ヒントやベストプラクティスを共有できますか？例えば、どのスキルを使っていますか？
Copilotが生成するテキストが、私が手書きで書いたもののように見えるように、独自のスキルを作成しました。
このスキルは、私が公開した65の記事から私の文体を学習しています。そのため、下書きは言語モデルのような文体ではなく、私のブログのような文体で返ってきます。このプロジェクトのドキュメントを生成する際には本当に便利で、LLMが12年間のブログ執筆から学び、表現力、テスト容易性、シンプルさといった同じ原則に沿った例を提供できるようになります。
ソフトウェアエンジニアとしてのキャリアを通じて、コードの作成よりも保守にはるかに多くの時間を費やすことを学びました。そのため、既存の製品にとっては保守と安定性が極めて重要であることから、AIが最小驚愕の原則に従って既存のコードの作法を模倣できるようにするスキルを開発しました。
ひとつのヒントは、操作の種類に応じてモデルのタイプを変えることです。徹底的な思考には、100万のコンテキストウィンドウとExtra HighまたはMaxの推論を備えたOpusを使用します。しかし、レポートの生成、リリースノートの作成、ドキュメントの検証といったより単純なタスクには、トークン消費の少ない軽量なモデルを使用します。
Patrick Baumgartner
GitHubプロフィール: @patbaumgartner
あなたの仕事はチームのコーチングです。どのようなアプローチを取っていますか？
私の仕事の多くは、通常のビジネスが引き続き稼働している中で行われます。「変革」のためにすべてを6か月間止めることはできません。私たちは通常、まず一緒に緊急の問題を解決することから始め、チームが現在どこにいるのかを把握し、どこに向かいたいのか、そして改善していることをどうすれば確認できるのかを定義し、その後、一歩一歩そこへ向かって進みます。
状況によりますが、それはTDD、リファクタリング、継続的デリバリー、XPといったSoftware Craftのプラクティスを意味することもあれば、Spring Boot、Spring Modulithを使ったアーキテクチャとモジュール化、Spring Security、コンテナ向けのJavaおよびSpring Bootアプリケーションの最適化、あるいはますます増えているエージェントエンジニアリングを意味することもあります。
私にとって重要なのは、私が働いているということです と共に チームです。私たちは一緒に意思決定をします。チームが私に依存するようにはしたくありません。理想的には、しばらく経てば、私がスパーリング相手として必要になるくらいで、もう私を必要としなくなることです。
そして、もしかするとそれが、私がこの新世代のAIツールにとても興味を抱く理由を説明しているのかもしれません。私は人々と一緒に働き、学び、実験し、問題を解決するのが好きだからです。AIは、まさにそれを行うためのもう一つの非常に強力なツールを私たちに与えてくれます。
GitHub Copilot が最近どのようにあなたの役に立ったか、良いエピソードを教えてもらえますか?
GitHub Copilot との付き合い方について私の考えを変えた、実際にはまったく異なる3つの例があります。
まずは1つ目から始めましょう。
1つは、15件のプレゼンテーションにわたる約900枚の教習用スライドをReveal.jsからMarpへ移行する作業でした。これらは単純なスライドではありませんでした。多くにはコード、アニメーション、さらには授業中にJavaScriptをライブで変更できるインタラクティブな例が含まれています。さらに重要なのは、これらのプレゼンテーションがすでに学生相手に実戦で試練を経ていたことです。流れはうまく機能していました。小さな一片を失うだけでも、教室で使っているストーリーが壊れかねませんでした。
その移行を手作業で行っていたら、おそらく1週間以上かかっていたでしょうし、現実的には、こんなに退屈な作業だったので、単にやらないで済ませていたかもしれません。
Copilotについては、私は異なるアプローチを取りました。まず既存の資料を分析し、目標を定義し、移行計画を作成し、制約を確立し、例を示し、そのまま維持すべき内容を定義しました。その上で、大規模な構造の変更から細部へと作業を進めました。
本当に重要だったのは検証の部分でした。
Reveal.js 版と Marp 版のスクリーンショットを生成し、視覚的およびアルゴリズム的に比較しました。両方のスライドデッキを並べて実行し、アニメーションを手動で確認できる小さなアプリケーションを作成しました。生成された PDF まで比較しました。
つまり、エージェントは単に「移行完了」と言うだけではありませんでした。証拠があったのです。
移行全体にはおよそ8〜10時間かかりました。それでも、コンテンツ、教える意図、そして意味のある変更はすべて私自身のものです。Copilotは誤字を自動的に直すことはできましたが、コンテンツ、バージョン、日付、意味が変わる場合は、私たちで話し合って決めていました。
私にとって、あの経験は重要な原則を改めて思い知らせてくれました。 責任を委譲するのであって、実行を委譲するのではない。 結果に対する責任は私が負う。
2つ目の例を共有してもらえますか？
2つ目の例は、TambouiでターミナルUIアプリケーションを構築した際に生まれたものです。当初はWSL上のLinuxで完璧に動作しており、誰かがWindowsのCMDやPowerShellで直接実行する可能性をすっかり忘れていました。
そして実際のユーザーがそれをやりました。
そのユーザーは、一部のフォームでEnterキーが完全に無視されることを発見しました。これは私が強く信じているもう一つの原則です。ソフトウェアは早くリリースしましょう。人が実際にどう使うかから学べるのはそこだからです。
私たちはCopilotを使って、そのフィードバックを再現可能なUIテストに変えました。LinuxではCopilotがtmuxを使ってアプリケーションを操作していました。その作業を通じてpsmuxの存在を知り、PowerShellでも同様のフローを実行できるようになりました。問題を再現し、ローカルで修正を作成し、本当の問題がTamboui側にあることを突き止め、私はアップストリームへの修正を提出し、それはマージされました。
この作業中、テストの説明そのものが利用可能なコンテキストに対して大きくなりすぎました。そこで私はCopilotに、テストの表現方法を再設計する手伝いを頼みました。識別子、名前、繰り返しの説明を含む冗長なテーブルの代わりに、Copilotははるかにコンパクトな矢印記法、つまり step → step → input という形式を提案し、追加情報は本当に重要な箇所にだけ記述するというものでした。
これは私を驚かせました。私たちは単にAIに情報の実行をさせていたのではなく、 実行のためには情報をどう表現すべきかについて共に取り組んでいたのです。人間にとって最大限分かりやすいものである必要はなく、意味論を保ちながらエージェントにとって効率的であることが求められていました。
3つ目の例はどうですか？
3つ目の例はまたまったく違うものです。
身近な人が数学の練習を必要としていて、私はこう考えました。小さな学習アプリを作ってみませんかと。
このアプリは小学1年生から4年生までを対象に、足し算、引き算、掛け算、割り算、余りのある割り算をカバーしています。しかし、また単純なクイズアプリを作りたかったわけではありません。Copilotと一緒に、分散反復、即時フィードバック、適応的な難易度、モチベーション、協同学習、そしてダークパターンを使わないゲーミフィケーションといった学習アプローチを調べました。
興味深いことに、その調査の過程でCopilotは私の当初の前提の一つに異議を唱えました。私は最初、このアプリを世界中の子供たちにとって汎用的なものにしたかったのです。しかし調査の結果、実際の学校のカリキュラムを見る方向に進みました。トピックが導入される順序、演算、数の範囲は国によって十分に異なるため、最初から「汎用的」にする必要はないと気づいたのです。
そこで私たちはまずスイスに焦点を当て、学習の進め方をそれに合わせました。スイスは多言語国家であるため、アプリはドイツ語、フランス語、イタリア語、英語で利用できます。
さらに協力型と競争型の2人プレイモードも備えており、答えを間違えたときには、アプリが一つの解き方を説明し、類似の問題を分散反復を通じて再び出題します。
私は意図的にバックエンドを持たないアーキテクチャを選びました。子供の個人データをサーバー上で収集する理由はまったくないので、データはデバイス上にとどまり、アプリケーションはGitHub Pagesにホストするだけで動きます。
小さな実験として始まったものが、今では友人たちの間で使われ、共有されています。偶然にも小さなプロダクトになったのです。
この経験はCopilotのもう一つの側面を教えてくれました。自分の解決策の実装だけに使うのではなく、 構築を始める前に解決策の空間を広げ、挑戦させるスパーリングパートナーとして使いましょう.
普段はどのようにCopilotを使っていますか？
実は、もう古典的なCopilotのオートコンプリートの使い方はしていません。
私の仕事は、ほぼ完全にエージェント型のワークフローへと移行しました。
密接な視覚的フィードバックループが必要なとき、つまりドキュメント、コード、プレゼンテーション、中間結果をじっくり確認し、進めながらプロセスを調整したいときには、VS Code を使います。
より大規模な実行志向のタスクについては、ターミナルからコーディングエージェントを使って作業することが多いです。その場合、仕事のひとまとまりを委任して実行させ、完成した結果を確認する方がやりやすいと感じています。どのインターフェースを選ぶかは、主に必要とするフィードバックループ次第です。
JavaLandに向かう移動中、GitHub経由でコーディングエージェントのワークフローを使った興味深い経験をしました。Spring Bootのオートコンフィグレーションのどれをロードするかを最適化するMavenプラグインのアイデアを探り始めていました。およそ4時間の旅の間、私はスマートフォンからエージェントを指揮していました。タスクを与え、エージェントが行ったことをレビューし、次のステップを考え、次の指示を送るという具合です。
到着する頃には、動作するMavenプラグイン、CIパイプライン、サンプルアプリケーションに対するパフォーマンステスト、そしてその最適化が実際に機能するかを示せるレポートが揃っていました。
このやり方で作業したのは初めてで、実際にうまくいったことに驚きました。スマートフォンでJavaを書こうとしていたのではなく、 エージェントが実行する間に、レビューし、決定し、指揮していたのです.
有用な機能やコンテキストを提供してくれる場合は、MCPサーバーも使っています。たとえば、ドキュメント用にContext7を使ったり、Logseqナレッジベースとの統合を使ったりしました。また、Adobe Premiere ProのMCP統合も試してみました。
しかし、できるからという理由だけでMCPを使うわけではありません。優れたCLIが存在するなら、私にはより直接的で速く感じられるため、しばしばCLIを好んで使います。
私の思考モデルの中で、エージェントは「ジュニア開発者」ではありません。むしろスパーリングパートナーだと考えています。しかし、プロジェクトに参加する誰もがそうであるように、まずキャッチアップさせる必要があります。
コンテキストこそが王です。
ヒントやベストプラクティスをいくつか共有できますか？
最もおすすめしたいことは次のとおりです。 ワンショットのプロンプティングをやめることです。
些細でないことについては、実行が始まる前に問題を理解したいのです。かなり頻繁に、エージェントにまず私をインタビューするよう明示的に求めます。そのインタビューの目的は、まだ暗黙的なままになっている前提や期待を明らかにすることです。
優れたエージェントは、間違ったアイデアを信じられないほど速く実行できてしまいます。それでも回り道のコストは安くなりません。
私自身、Spring Bootオートコンフィグレーションオプティマイザーの作業中にこれを経験しました。最初はSpring Boot 3.5と4.xの両方をサポートしようとしていました。アーキテクチャ上の違いがあったため、両方のアプローチを実装しました。後に3.5のパスが不要になったと気づき、削除するのは苦痛でした。
教訓はシンプルでした。 回り道は高くつく。加速する前に要件を正しく固めることです。
意図が明確になったら、プランが欲しくなります。そのプランをレビューするとき、特に重要だと考えるのは4つの点です。前提が可視化されているか、検証ゲートが定義されているか、アプローチがアーキテクチャに合っているか、そして不必要な作業を避けられているかです。
2つ目の原則は、 タスク固有の検証ゲートを定義することです。
「完了」は、モデルが完了したと言うことを意味してはなりません。
リファクタリングの場合、ゲートにはテストの成功、対象ファイルすべてが処理されたことの証明、ドキュメントの更新、TODOが残っていないことなどが含まれるかもしれません。スライドの移行の場合、ゲートにはスクリーンショット、ビジュアル差分、アニメーション、PDF出力、コンテンツの完全性が含まれていました。
ゲートはタスクに依存します。しかし原則は依存しません。エージェントは、作業が完了の定義を満たしていることの証拠を提示できなければなりません。
最近、似た考え方に基づく unlazy というスキルを見つけました。明示的なゲートを作り、それらに沿って計画的に作業を進め、近道をせずに完了したことを証明するというものです。
3つ目の原則は、学んだことを 再利用可能なスキルに変えることです.
私は自分自身のAgent Skillsを書き、管理し始めました。実行から何かを学ぶたびに（エージェントが規約を誤解したのかもしれない、有用なチェックが欠けていた、あるいはタスクへのより良いアプローチを見つけた）、スキルを更新します。
次にそのタスクを行うときには、教訓がすでにそこにあります。
一例として、オープンなagent skillsコミュニティでの活動に触発された maintainer-auditと呼んでいるスキルがあります。自分のリポジトリ全体で使っています。保守されたプロジェクトに期待する事柄、すなわちリポジトリのドキュメント、CIパイプライン、Dependabot設定、CodeQL、一貫したクリーンアップ、その他のプロジェクト標準をチェックし、必要に応じて修正します。
目的は、私が読むための監査レポートをもう1つ生成することではありません。リポジトリを、私が望むベースラインへ自動的に戻すことです。それによってプロジェクトはより一貫性があり、保守しやすくなります。
私はこれらのスキルを 生きたエンジニアリング知識 静的なプロンプトではなく。
第4の原則は、確率的なモデルの周囲に決定論的なエンジニアリングツールを配置することです。
私はCheckstyle、PMD、Spring Modulithのアーキテクチャチェックといったツールをラップし、エージェントが利用できる統合レポートを生成する独自の品質ハーネスを持っています。それをhooksから実行し、エージェントに反復させることができます:
変更 → チェックを実行 → 指摘を読む → 修正 → 再実行。
指摘がなくなるまでこれを続けます。
だからといって、ソフトウェアを目で確認するのをやめるわけではありません。私は今でもアプリケーションを実行し、操作し、期待どおりに動作し、期待どおりに見えるかを判断します。フィードバックループがはるかに短くなるため、機能ごとに意図的に実装することもあります。
「AIならできるから」と一度にすべてを求めるのは、たいてい悪い考えだと学びました。大きく汎用的な仕様は大きく汎用的な実装を生み出し、その後のクリーンアップは、より小さな増分を正しく構築するよりも難しくなりがちです。
より広く言えば、私たち開発者は、 どのように これらのツールを使うかについて、もっと多く語り合う必要があると思います。うまくいった実験を共有する。うまくいかなかった実験も共有する。唯一普遍的なAI開発プロセスを探すのではなく、互いのアイデアを借りて、自分の状況に合わせて適応させることです。
だからこそ、私はAIをスパーリングパートナーとして使うという発想が気に入っています。金曜の夜、何か実験をしたいけれどペアになってくれる人がいないとき、私は突然、アイデアをぶつけたりアプローチを見直したり、あるいは非常に高性能なラバーダックとして利用できる相手――誰か、あるいは何か――を手に入れることができるのです。
とはいえ、それらのアイデアはやはり実際の人間に持ち帰ります。人間からのフィードバック、プロダクトへの理解、そして現実世界の文脈は依然として不可欠です。
AIが私たちの職業をどう変えていくと思いますか?
ソフトウェア工学を学ぶ学生は、主にコードを生み出す機械になることを目指すべきではないと考えています。彼らは強力な問題解決者になる必要があります。ユーザーやステークホルダーを理解し、要件の背後にある本当の問題を発見し、前提に疑問を投げかけ、プロダクトと市場を理解し、アーキテクチャ上のトレードオフを判断し、批判的に考え、構造化された方法で作業し、有用なソリューションをある文脈から別の文脈へと転用できるようになる必要があります。
モデルは可能性を生成し、物事を実行することにおいて非常に優れています。しかし人間である私には、誰も文書化したことのないものまで含めた、実際の文脈をはるかに多く知っていることが通常です。
だからこそ私は、ソリューションの形を決める役割にはとどまり、実行の多くをエージェントに任せたいのです。
その意味で、私はこう考えています。 AIはソフトウェアエンジニアリングに、再び「エンジニアリング」を取り戻しつつある.
そしてそれは私が好ましく思うことです。
Frank Delporte
GitHubプロフィール: @FDelporte
どのようにしてテックの世界に足を踏み入れましたか?
11歳のときにCommodore 64を手にして以来、コンピューターに魅了されてきました。学校卒業後はビデオ制作やテレビの仕事に少し脇道へ逸れましたが、ビデオをDVDに入れる必要があったことや、最初期のウェブサイトに関わったことなどがきっかけで、コーディングの世界に戻ってきました。ええ、私はそれほど古い人間なんです ;-).
最近、GitHub Copilotはどのように役立っていますか?
プルリクエストの評価やバグレポートの調査には、完璧な相棒です。
印象的な話のひとつが、 Pi4Jライブラリ についてです。これは、Raspberry Pi上の電子部品とやり取りするJavaアプリケーションを構築できるようにするものです。2026年2月、私たちはForeign Function & Memory APIを使用する新しいプラグインを備えたV4をリリースしました。リリース前に入念にテストしましたが、それでもリリース直後、ある人が 5つの入力ボタンを使うと期待どおりに動作しないと報告しました。設定された最初の4つのボタンのいずれかを押すと、期待どおりにコードが実行されるのですが、5つ目のボタンでは何も起きないのです。
これは望まない種類のレポートでした。見た目には何も壊れていません。例外もなく、ログに警告もなく、5つ目のボタンは単に沈黙していました。さらに悪いことに、古いgpiodプラグインでは、まったく同じハードウェアでまったく同じアプリケーションが正常に動いていたのです。つまり問題は、LinuxカーネルのGPIOキャラクタデバイスの上に位置し、ネイティブ呼び出しを通じてそれと通信する、新しいFFMコードにあったのです。コードベースの中でも、簡単な答えが見つかるとは期待できない部分です。
そこで私はこの課題をCopilotコーディングエージェントに割り当て、出発点として2つのファイルパス、プロバイダクラスとFFMDigitalInputを与えました。約30分後、プルリクエストが届きました。そしてその説明は、本当に予想外のものでした。
各入力は、ネイティブの poll() 呼び出しの中でブロックするイベントウォッチャを実行し、カーネルがGPIOライン上の変化を報告するのを待ちます。これらのウォッチャは仮想スレッドで実行されていました。そして、ネイティブ呼び出しの中でブロックしている仮想スレッドは、キャリアスレッドからアンマウントすることができません。呼び出しの全期間、そこにピン留めされたままになります。Raspberry Pi 4には4コアあるため、仮想スレッドスケジューラには4つのキャリアスレッドがあります。入力を4つ登録すると、4つのキャリアすべてが poll() の中で駐車してしまいます。5つ目のウォッチャは作成されますが、決してスケジュールされません。まさに報告されたバグがこれです。「イベントが不安定」ではなく「5つ目が何もしない」という現象です。
私が最も気に入ったのはdiffではなく、その後のレビューでの会話でした。私は、さらに詳しく説明するようCopilotに求めるコメントを残しました。
仮想スレッドの目的はまさにプラットフォームスレッドの制限から離れることだったのでは? では、4コアプロセッサであるRaspberry Pi上で、なぜ4つの仮想スレッドが4つのスレッドをブロックすることが問題になるのでしょうか?
完全なやり取りは プルリクエストを確認してください。Copilotは、4つのCPUコアを持つRaspberry Piの使用と報告された問題を結びつけることができました。そして問題に対するシンプルな修正案を提示できるだけでなく、調査中に見つけた追加の改善点も提案してくれました。
ヒントやベストプラクティスをいくつか共有できますか?
- どこを探すべきかを伝える: Pi4J の issue #622 では、私は2つのファイルパスを追加しました。これはわずかな手間ですが、大きなコードベース内での膨大な検索を省いてくれます。バグについては見当がつかなくても、その周辺領域についてはたいてい勘が働くものです。ツールにそれを伝えれば、コード全体を調べる必要がなくなります。
- 証拠とテストを求める: 「変更を検証する単体テストを追加して」は、最近私がよく頼むことです。というのも、頼んだ、という過去形なのは、今や私の指示ファイルのルールになっているからです。これにより、診断が間違っていた場合も防げます。テストが古いコードで失敗しないはずだからです。
- なぜかを尋ねる: 修正内容が理解できない場合は、その旨を伝えて質問しましょう。その説明も成果物の一部であり、プロジェクトのドキュメントや、チケットやプルリクエストの中に追加されるべきものです。後にその情報を読む人全員のためになります。たとえば、このことも、Pi4J チーム内でネイティブ呼び出しにおける仮想スレッドのピニングについてさらなる議論を引き起こしました。
- 主導権を握りましょう: Pi4J のこれらのプルリクエストは、すべてマージ前にメンテナーによってレビューされ承認されました。それがこのプロジェクトで最も上手く機能しているモデルです。エージェントが調査を行い、人間が出荷されるものに責任を持ちます。また、私の他のプロジェクトでも、ツールが生成したコードは必ずレビューするようにしています。コードは常に読みやすく保守しやすい状態に保ちたいのです。ツールが重複したメソッドを作ったり、別の場所にすでに存在して統合すべきものを再作成してしまうことはあまりにも多いです。それはあなたの責任です。今では AI 支援のコーディングで非常に速く作業できますが、それは同時に、非常に速く混乱を作り出せるということでもあります。そうしないでください。コードを管理しやすい状態に保ちましょう。後でバグを調査したり改善を行うことになった同僚や未来の自分が感謝してくれるでしょう。
タグ:
執筆者
Principal Cloud Advocate
関連記事
AI & MLVS Code で GitHub Copilot アプリのセッションを継続する方法
会話、コードの変更、作業コンテキストを失うことなく、エージェントセッションを GitHub Copilot アプリから VS Code へ移行する方法を学びます。
AI & MLGitHub のシークレット検出モデル：より少ないノイズでより多くのシークレットを検出
GitHub のコンテキスト認識型シークレット分類器は検出品質を向上させ、重み付き承認率を 11.5% 引き上げ、スキャン実行時間の中央値を 86% 短縮しました。
AI & ML初心者向け GitHub Copilot アプリ：Copilot にあなたのコードベースを教える方法
リポジトリにカスタム指示とスキルを追加する方法、カスタムエージェントの使用方法、Playwright などの MCP サーバーの接続方法を学びます。