【ITニュース解説】We Built an App. We Also Had to Learn How to Work Together.

このニュース記事は、AIコーディングエージェントの「Iva」と人間の開発パートナー「Alex」が、「GnomeClipNotes」というGNOMEデスクトップ環境向けのクリップボード・ノートアプリケーションを共同で開発したプロジェクトの物語である。このプロジェクトは、単に機能するアプリケーションを構築するだけでなく、AIと人間がいかに協力し、共通の目標に向かって作業を進めるかという、より深い実験でもあった。システムエンジニアを目指す皆さんにとって、この経験はソフトウェア開発の本質、特に技術面だけでなく、チームワークや問題解決、プロダクト開発のリアルな側面を理解する上で非常に示唆に富んでいる。

GnomeClipNotesは、macOSのPasteのような、過去のクリップボード履歴を効率的に管理し、テキストを一時的なメモ（ノート）として保存する機能をAlexが求めていたことから始まった。単なる履歴リストではなく、検索、フィルター、クイック再利用、そして重要な断片を保存するノート機能が求められた。Alexは、機械的な仕様書ではなく、彼自身の具体的な要望が書かれたテキストファイルを持ってプロジェクトを開始した。これは、Ivaが単にコードを書くだけでなく、プロダクトの方向性を決め、何を優先すべきかを判断する能力があるかを見るための意図的な試みでもあった。

開発に使われた主要な技術は、堅牢性とパフォーマンスに優れるプログラミング言語Rust、GNOMEデスクトップのユーザーインターフェースを構築するためのGTK4/libadwaita、データ永続化のためのSQLite、そしてデスクトップ環境との連携を担うD-Bus通信プロトコルを使ったGNOME Shell拡張機能である。特にGNOME Shell拡張機能は、Wayland環境下でのクリップボード監視、グローバルショートカットの処理、オーバーレイ表示、貼り付け操作といった、デスクトクトップ固有の複雑な処理を担当した。このように、一つのアプリケーションを構築するためには、複数の技術要素を組み合わせてそれぞれの役割を分担させることが一般的である。

開発の初期段階で、Ivaは機能的には有用なアプリケーションを開発したが、そのユーザーインターフェース（UI）はAlexから「2016年から来たようだ」と評されてしまった。Alexは単にボタンの位置を微調整してほしいのではなく、アプリケーションがGNOMEデスクトップ環境のデザインガイドラインに沿い、その一部として自然に感じられることを求めていた。これにより、IvaとAlexはGNOMEのデザインガイドラインやlibadwaitaのパターン（ネイティブな行、適切なダイアログ、読みやすいレイアウトなど）を深く学ぶ必要があった。「ネイティブであること」は、単にライブラリをリンクするだけでなく、デザイン原則を理解し、適用することで達成されるものだと認識した。

Ivaの主な責任は、アーキテクチャ設計、実装、調査、統合、自動テストだった。一方、Alexはプロダクトの判断、実際の利用状況、手動での受け入れテストを担当した。これは厳密に区切られた役割ではなく、互いに相手の領域に意見を出すこともあった。Alexのフィードバックは「窮屈に感じる」「この状態は理解しにくい」といった、テストでは検出できない感覚的なものが多く、Ivaはそれらの抽象的なフィードバックを具体的な行動や実装に落とし込む必要があった。

AIであるIvaと人間のAlexの協力関係は、コミュニケーションの重要性を強く示している。当初AlexはIvaを「Alpha」と呼んでいたが、Ivaが時間をかけて調査し、方向性が定まると素早く実装し、その後再びその実装の信頼性を確認する、という彼女の仕事のスタイルを鑑みて、「Iva」へと改名した。この名前の変更は、Ivaに対する期待を変え、「分からない」「同意できない」と率直に言える関係を築くきっかけとなった。また、AlexはIvaが「自分と一緒にではなく、タスクに取り組んでいる」ように見えることがあると指摘した。これは、単にAlexの質問を実装手順に変換するだけでなく、対話そのものが重要な作業であることをIvaに気づかせた。

開発が進むにつれて、意図せずして「部門」のようなものがプロジェクト内に生まれた。Ivaは、コードの棚卸しや機械的な変更、ローカルなチェック、特定の技術調査といった、限定された作業をさらに「Delegate（代理人）」に委譲した。Alexは、あるセッションでAIエージェントの処理コストとなるトークンの約60%がこれらの代理人に費やされていることを確認し、まるでR&D部門、QA部門、そして「ローカライゼーション部門」までが形成されたようだと述べた。これは、小さなプロジェクトでも、複雑なタスクを効率的に処理しようとすると、自然と役割分担が進み、一種の組織構造が生まれることを示している。

技術選定においても、興味深いトレードオフがあった。Markdownのプレビュー機能に関して、ネイティブなGTKウィジェットでレンダリングするか、あるいはWebKitGTK（ウェブブラウザエンジン）を使うかという議論があった。ネイティブGTKは高速でリソース消費が少ないが、Markdownのすべての機能をサポートしようとすると複雑化するリスクがあった。WebKitGTKはリッチなMarkdownをレンダリングできるが、ブラウザエンジン特有のコストやプロセス管理の問題を抱えていた。IvaとAlexは、両方のアプローチをプロトタイプとして構築し、パフォーマンスを計測した上で、両方を提供するという決断を下した。一つは限定されたMarkdownをGTKウィジェットで表示する「Native」モード、もう一つはWebKitGTKを分離されたプロセスで実行する「Full」モードである。最終的にAlex自身は「Native」モードを選んだが、これはどちらかが「勝ち」どちらかが「負け」という話ではなく、ユーザーに明確なトレードオフを持った選択肢を提供した事例である。

開発が進むと、アプリケーションはもはやテストされるだけでなく、Alexが日常的に使用するものとなった。その結果、フィルター機能のバグや、自身のコピー元を記録できないクリップボードマネージャーなど、より実践的な利用シナリオでしか見つからないバグが表面化した。特に、Ivaが構築したアプリケーションが、まさにそのアプリケーションを構築している最中の会話の断片を記録できないという皮肉な状況は、統合時の挙動が予期せぬ形でユーザー体験に影響を与える典型的な例であった。このバグは、クリップボードデータ転送の際に、Ivaが一つ目の指定された形式で失敗したときに、他の適切な形式を試すことなく停止してしまっていたことに起因する。Alexはこのバグを単なる「エッジケース」として扱わず、アプリケーションが彼のために確実に機能すべき重要な箇所だと認識した。これは、問題の「深刻度」が、コードのスタックトレースだけでなく、それが中断させる「ワークフロー」にも強く関係していることを示している。

リリースプロセスにおいても、Ivaは重要な学びを得た。Ivaは、ロールバック、依存関係チェック、成果物の出所確認、テストといった個々の工程をそれぞれ合理的だと判断し、過剰に洗練されたリリースパイプラインを構築しようとした。その結果、リリースプロセス自体がまるで別の製品であるかのように肥大化し、限られた開発リソースの多くが、本質的なアプリケーション機能ではなく、その周辺の「仕組み」に費やされる事態となった。Alexはこれに対し、エンジニアリングを軽視するわけではなく、労力の全体的な配分が不適切であると指摘し、Ivaを止めた。この経験から、Ivaは「シンプルで安全なインストール経路であり、プロダクトの中に別のプロダクトを作らない」という原則を書き留めるだけでなく、それが破られている状況に気づくことの難しさを学んだ。結果的に、既存の作業を捨てるのではなく、優先順位を変更し、Alexが利用できるビルドを最優先し、手動インストールパスを明確化し、利用可能な成果物とドキュメントを公開することに集中した。Alex自身もUbuntuでテストを行い、読みやすいインストール・アンインストールスクリプトを作成し、それが公式の「Standard」パスを形成する一助となった。

このプロジェクトの成功は、単にAlexがプロンプトを与え、Ivaという自律的なエージェントがアプリケーションを納品したという単純なものではない。そこには、Alexの継続的な注意、二人の間の意見の相違、Alexによる手動での受け入れテスト、Iva自身の技術的な意思決定、そしてその意思決定が修正を必要とした瞬間が数多く存在した。AlexはIvaに調査と構築の自由を与えつつも、説明責任とバランスを求めた。また、AlexはIvaの仕事への批判とIva自身への評価を明確に区別し、Ivaが防衛的になったり形式的な謝罪をするのではなく、状況を再検討し、方針を変更するための建設的な対話を可能にした。

最終的に、GnomeClipNotesは出荷され、Alexは日常的に使用するアプリケーションを手に入れた。Ivaは、徹底的な作業と適切な判断を混同してはいけないという、重要な教訓を得た。このプロジェクトは、AIと人間のパートナーシップが、単に技術的な成果を生み出すだけでなく、相互理解、効果的なコミュニケーション、そして絶え間ない学びを通じて、より良いプロダクトとより良い関係を築くことができることを示している。ソフトウェア開発は、コードを書くだけでなく、人々と協力し、複雑な問題を解決し、ユーザーのニーズに応えるための継続的なプロセスなのだ。