はじめに
GitHubが2026年1月28日に公開した技術記事では、GitHub Copilot CLIの起動時に表示されるアニメーションASCIIバナーの開発プロセスが詳しく解説されています。一見シンプルに見える3秒のアニメーションですが、その背後には6,000行以上のTypeScriptコードと、ターミナル環境特有の複雑な技術的課題への対応がありました。本稿では、この開発事例を通じて、ターミナルUIにおけるアニメーション実装の技術的困難さと、その解決アプローチについて紹介します。
参考記事
- タイトル: From pixels to characters: The engineering behind GitHub Copilot CLI’s animated ASCII banner
- 著者: Aaron Winston
- 発行元: GitHub Blog
- 発行日: 2026年1月28日
- URL: https://github.blog/engineering/from-pixels-to-characters-the-engineering-behind-github-copilot-clis-animated-ascii-banner/
要点
- GitHub Copilot CLIの起動バナーとして、3秒間で約20フレームのASCIIアニメーションが実装され、その開発には6,000行以上のTypeScriptコードが必要だった
- ターミナル環境ではブラウザと異なり、キャンバスやレンダリングモデルが存在せず、ANSIエスケープコードの動作も環境ごとに異なるため、アニメーション実装が極めて困難である
- ANSIカラーコードは環境によって解釈が異なり、ユーザーのアクセシビリティ設定によって色が上書きされるため、セマンティックなカラーロールシステムが採用された
- デザイナーのCameron Foxlyが、フレームベースのASCII編集ツールを独自開発し、エンジニアのAndy Fellerと協力して本番環境への統合を実現した
- アクセシビリティを最優先し、アニメーションはオプトイン方式とし、スクリーンリーダーモードでは自動的にスキップされる設計となっている
詳細解説
GitHub Copilot CLIの新機能
GitHubによれば、GitHub Copilot CLIは、プロジェクト計画、ファイル修正、コマンド実行、カスタムエージェントの使用、クラウドへのタスク委任など、エージェント的なワークフローをターミナル上で直接実行できるツールです。導入以降、持続的なメモリ、無限セッション、インテリジェントな圧縮機能などが追加され、より柔軟なワークフローをサポートしています。
また、これらのエージェント機能は、GitHub Copilot SDKを通じて他のツールやプロダクトにも組み込むことが可能です。このSDKは、Copilot CLIと同じ実行ループを公開しており、開発者は自身のアプリケーションにエージェント機能を統合できます。
ASCIIアニメーションが高度な技術課題である理由
記事では、ターミナルでのASCIIアニメーションが技術的に困難である理由が、いくつかの観点から説明されています。
まず、ターミナルには「キャンバス」の概念が存在しません。ブラウザ(DOM)、ネイティブアプリ(ビュー)、グラフィックスフレームワーク(GPUサーフェス)とは異なり、ターミナルは出力を文字のストリームとして扱います。そのため、フレーム、スプライト、Z-index、ラスタライズされたピクセル、アニメーションのティックレートといった概念が存在せず、すべてのフレームをカーソル移動と再描画コマンドを使って手動で再ペイントする必要があります。
ウェブブラウザでは、複数のレンダリングエンジンが存在するものの、DOM構造、アクセシビリティAPI、WCAGなどの標準が確立されています。一方、ターミナル環境は、VT100のような数十年前のハードウェアから継承された動作のパッチワークであり、統一された標準がほとんど存在しません。
ANSIカラーコードの複雑性
ANSIエスケープコード(例:\x1b[35mは明るいマゼンタ、\x1b[Hはカーソルホーム)の動作が、ターミナル間で一貫していないことが指摘されています。Windows Command PromptやPowerShellの古いバージョンでは、追加設定なしにANSIサポートが制限されているか、全くサポートされていない場合があります。
さらに、ANSIをサポートするターミナルでも、最も困難なのはカーソル移動ではなく、色の扱いです。CLI開発において、色の扱いには現実的に3つのアプローチがあると説明されています。
1つ目は、色を全く使わない方法です。これは広範な互換性を保証しますが、意味を強調したりユーザーの注意を誘導したりすることが難しくなります。
2つ目は、より豊富なカラーモード(3ビット、4ビット、8ビット、トゥルーカラー)を使用する方法ですが、これらは一様にサポートされておらず、カスタマイズもできません。異なるターミナル、テーマ、アクセシビリティプロファイルで同じカラーコードが異なってレンダリングされ、ユーザー間で「良い」色についての意見も分かれます。
3つ目は、最小限のカスタマイズ可能なパレット(通常は4ビットカラー)を使用する方法で、これはほとんどのターミナルでユーザーが設定で上書きできます。これが最も安全な選択肢ですが、ブランドパレットを正確に表現できる能力が制限され、コントラストやテーマの選択が大きく異なる環境向けの設計を強いられます。
Copilot CLIアニメーションでは、色を「セマンティック」なシステムとして扱うことにしました。具体的なRGB値をコミットする代わりに、高レベルの「ロール」(目、ゴーグル、影、ボーダー)をANSIカラーにマッピングし、異なるターミナルやアクセシビリティ設定間で適切に劣化するようにしています。
アクセシビリティへの配慮
ターミナルは、スクリーンリーダーを使用する視覚障害者だけでなく、弱視のユーザー、色覚異常のユーザー、ハイコントラストやカスタマイズされたテーマで作業するユーザーなど、さまざまな視覚能力を持つ開発者に使用されています。
そのため、以下の点に配慮する必要があります。高速な再レンダリングはスクリーンリーダーにとって聴覚的なノイズになる可能性があり、色に基づく意味は安全に劣化する必要があります。これは、太字、薄暗い色、微妙な色合いが知覚できない場合があるためです。弱視のユーザーは、デザイナーが期待するコントラストの違いを見ることができない場合があり、アニメーションは自動ではなくオプトインでなければなりません。また、クリアシーケンスは支援技術を混乱させないようにする必要があります。
Copilot CLIアニメーションが初期段階でオプトインフラグの背後に置かれたのも、このアクセシビリティの制約が最初からアーキテクチャを形成したためです。
Inkの役割と限界
GitHubの説明によると、Inkはターミナル用のReactレンダラーで、JSXコンポーネントを使用してCLIを構築できますが、すべての状態変更で再レンダリングされ、フレームデルタを管理せず、ターミナルのペイントサイクルと同期せず、フリッカーやカーソルゴーストを解決しないため、アニメーションロジックは手作業で構築する必要がありました。
一般的なウェブ開発では、ReactやVueなどのフレームワークがレンダリングを最適化し、仮想DOMを使って差分更新を効率化します。しかし、ターミナル環境ではこうした最適化が限定的で、標準出力への書き込みとANSI制御シーケンスを直接管理する必要があります。
フレームベースASCIIアニメーションのツール不足
記事では、ASCIIアート用のツールは存在するものの、フレームごとの編集、複数色ANSIプレビュー、カラーロールのエクスポート、Ink対応コンポーネントの生成、コントラストとアクセシビリティのテストといった機能を持つツールはほとんど存在しないと説明されています。
既存のANSIプレビューツールでさえ、異なるターミナルが色を再マッピングしたり、カーソル更新を処理したりする方法をシミュレートしないため、カスタムツールなしでは正確な設計イテレーションがほぼ不可能です。そのため、チームは独自のツールを構築する必要がありました。
デザインツールの開発
GitHubのブランドデザイナーであるCameron Foxlyは、Copilot CLI用のバナー作成を依頼された際、通常であればAfter Effectsで何かを作成し、アセットを引き渡すところですが、エンジニアがアニメーションフレームを手動でCLIに変換する時間がなく、より楽しいものを求めていたと述べています。
Claude Codeの静的なASCII導入画面を見たことがあり、Copilotにはもっと個性が必要だと考えていました。3DのCopilotマスコットが飛び込んでCLIロゴを表示するアイデアは適切に感じられましたが、1つのフレームを手動で作成しようとした後、そのアイデアはすぐに現実に直面しました。
Foxlyは「悪夢だった」と述べ、「これが存在するなら、自分のツールを作る必要がある」と考えました。彼は、VS Codeで空のリポジトリを開き、GitHub Copilotに、テキストファイルをフレームとして読み込み、それらを順次レンダリングし、タイミングを制御し、フリッカーなしで画面をクリアし、プリミティブな「UI」を追加できるアニメーションMVPのスキャフォールディングを依頼しました。
1時間以内に、モノクロームながら機能するプロトタイプができあがりました。しかし、色を追加した瞬間、ターミナル間の不整合とアクセシビリティの制約が、主要なエンジニアリング問題となりました。
ANSIカラー理論と現実世界の制約
Copilotブランドパレットは、ウェブには最適な鮮やかでハイコントラストなものですが、ターミナルでは非常に困難です。
ANSIターミナルは、16色モード(標準)、256色モード(拡張)、場合によってはトゥルーカラー(「24ビット」)をサポートしていますが、一貫性がありません。256色モードでも、ターミナルはユーザーテーマ、アクセシビリティ設定、ハイコントラストモード、明暗の背景、OS レベルの上書きに基づいて色を再マッピングします。
これは、正確な色相に頼ることができないことを意味し、変動性を考慮して設計する必要があります。Foxlyは、ANSIカラーロールで文字をペイントしながら、異なるターミナルでどのように見えるかをプレビューする方法が必要でした。彼はWikipediaのANSIテーブルのスクリーンショットを撮り、Copilotに渡し、ツール用のパレットUIをスキャフォールディングするよう依頼しました。
これにより、FoxlyはPhotoshopのようにANSI色のASCIIを、一度に1文字ずつペイントできるようになりました。しかし、今度はそれを実際のCopilot CLIコードベースにエクスポートする必要がありました。
Inkへのエクスポート
Inkは、JSXコンポーネントを使用してCLIを構築するためのReactレンダラーです。DOMに書き込む代わりに、コンポーネントは標準出力にレンダリングされます。
Foxlyは、Copilotに、フレームを受け取り、行ごとにレンダリングし、状態更新でアニメーション化し、CLIコードベースにきれいに統合するInkコンポーネントの生成を支援するよう依頼しました。記事では、簡略化されたInkフレームレンダラーと最小限のアニメーションラッパーの例が示されています。
これにより、Foxlyは自信を持ってプルリクエスト(GitHubでの9年間で初めてのエンジニアリングプルリクエスト)を開くことができました。Foxlyは「Copilotが私が知らなかった構文を埋めてくれた」と述べながらも、「でも、アーキテクチャ上の決定はすべて自分で行った」と付け加えています。
今度は、エンジニアリングチームがプロトタイプを本番環境に適したものに変える番でした。
本番環境への統合
GitHub CLIの背後にいる長年のGitHubエンジニアであるAndy Fellerは、Foxlyと協力してアニメーションをCopilot CLIコードベースに取り込みました。
ブラウザとは異なり、レンダリングエンジン、アクセシビリティAPI、WCAGのような標準を共有していますが、ターミナル環境は、VT100のような数十年前のハードウェアから継承された動作のパッチワークです。DOMも、セマンティック構造も、ターミナル全体で機能に関する部分的な合意しかありません。これにより、ターミナルでの「シンプルな」UI設計問題でさえ、独特に困難になります。特に、AI駆動のワークフローがCLIをより多くの開発者の日常的な使用に押し込むにつれて、その困難さは増しています。
Fellerは「ターミナルアニメーション用のフレームワークはない」と説明し、「フリッカーなしで、アクセシビリティを壊さずに、そして大きく異なるターミナル全体でこれを行う方法を見つける必要があった」と述べています。
技術的課題1:フリッカーなしのバナー表示
ほとんどのターミナルは、新しいコンテンツが到着すると、ビューポート全体を再ペイントします。同時に、CLIには厳格なユーザビリティの期待があり、開発者がコマンドを実行したとき、すぐに作業を開始したいと考えています。フリッカー、入力のブロック、または長すぎるアニメーションは、実際にはエクスペリエンスを低下させます。
これにより、チームが解決しなければならない核心的な緊張が生まれました。起動を遅くしたり、フォーカスを奪ったり、ターミナルレンダリングループを不安定にしたりすることなく、短いアニメーションバナーを導入する方法です。
実際には、これはターミナルが負荷の下で異なる動作をするという事実によって複雑になりました。一部は高速書き込みをスロットルし、クリアされたフレームを一時的に表示し、出力を異なる方法でバッファリングし、カーソル領域を一貫性なく再ペイントします。
iTerm2、Windows Terminal、VS Codeなどの一般的なターミナル全体でフリッカーを回避しながらCLIの応答性を保つために、チームは相互依存するいくつかの懸念事項を慎重に調整する必要がありました。アニメーションを3秒以内に保ち、ユーザーの対話を決して遅らせないこと、不要な再描画を最小限に抑えるために静的コンポーネントと非静的コンポーネントを分離すること、レンダリングをブロックせずにMCPサーバー、カスタムエージェント、ユーザー設定を初期化すること、Inkの非同期再レンダリングモデル内で作業することです。
結果として、アニメーションは非ブロッキングなベストエフォートの拡張として扱われ、安全にレンダリングできるときに表示されますが、起動パフォーマンスやユーザビリティを犠牲にすることは決してありません。
技術的課題2:ブランドカラーのANSIマッピング
Fellerによれば、「ANSIカラーの一貫性は単純に存在しない」とのことです。
最新のターミナルのほとんどは8ビットカラーをサポートしており、CLIは256色から選択できます。ただし、これらの色が実際にどのようにレンダリングされるかは、ターミナルテーマ、OS設定、ユーザーアクセシビリティ上書きに基づいて大きく異なります。実際には、CLIは環境全体で正確な色相や一貫したコントラストさえも信頼できません。
Copilotバナーには、追加の複雑さがありました。テキスト文字を使用してレンダリングされますが、ブロックレターのCopilotロゴは、読み取り可能な本文テキストではなく、グラフィカルオブジェクトとして機能します。アクセシビリティガイドラインの下では、非テキストグラフィカル要素はテキストとは異なるコントラスト要件を持ち、細部や正確な色の一致に頼ることなく知覚可能でなければなりません。
これを考慮するために、チームは意図的に最小限の4ビットANSIパレットを選択しました。これは、ほとんどのターミナルがユーザーがカスタマイズできる数少ないカラーモードの1つであり、ハイコントラストテーマ、弱視設定、カラー上書きの下でアニメーションが読みやすいままであることを保証します。
これは、チームが以下を行う必要があることを意味しました。Copilotワードマークを、適切なコントラスト要件を持つ非テキストグラフィカルコンテンツとして扱うこと、正確な色相に頼らずにCopilotパレットを近似するANSIカラーコードを選択すること、テキスト要素と非テキスト要素の両方についてWCAGコントラストガイダンスを満たすこと、明暗のターミナルでアニメーションが読みやすいままであることを保証すること、ユーザーがアクセシビリティのためにターミナルカラーを上書きしたときに適切に劣化すること、複数のターミナルエミュレーターとテーマ構成全体で色の組み合わせをテストすることです。
ブランドカラーを直接エンコードする代わりに、アニメーションは、ボーダー、目、ハイライト、テキストなどのセマンティックロールを、ターミナルが安全に再解釈できるANSIカラースロットにマッピングします。これにより、バナーはユーザーのカラー環境を制御することを前提とせずに認識可能なままでいられます。
技術的課題3:アニメーションの保守性
Foxlyのプロトタイプは、FellerがCopilot CLIに組み込むための優れた出発点でしたが、課題もありました。バナーは、11×78の領域をカバーする約20のアニメーションフレームで構成され、任意のフレームには約10のアニメーション要素をスタイライズする必要があり、フレームのテキストと関連する色を分離する方法が必要で、各フレームは行と列の座標にハードコードされた色をマッピングし、各フレームはFoxlyのビジョンを表示するために正確なタイミングを必要としました。
まず、アニメーションは、別個のライトテーマとダークテーマを作成するために使用できる別個のアニメーション要素に分解されました。記事では、AnimationElementsとAnimationThemeの型定義、ANIMATION_ANSI_DARKとANIMATION_ANSI_LIGHTのテーマ定義が示されています。
次に、アニメーション全体とその後のフレームは、アニメーションバナーに必要なコンテンツ、色、期間をキャプチャします。AnimationFrameとAnimationのインターフェース定義が示されています。
その後、各アニメーションフレームがキャプチャされ、フレームコンテンツをスタイリストおよびアニメーションの詳細から分離し、6,000行以上のTypeScriptとなり、大きく異なるレンダリングとアクセシビリティ動作を持つターミナル全体でCopilotロゴの3秒を安全にアニメーション化しました。
最後に、各アニメーションフレームがレンダリングされ、必要なANSIエスケープコードで連続した色の使用に基づいてテキストのセグメントを構築します。記事では、TypeScript/JSXコードの例が示されています。
技術的課題4:アクセシビリティファーストの設計
エンジニアリングチームは、GitHub CLIのアクセシビリティ作業と同じ哲学でバナーにアプローチしました。ターミナルとシステム設定の両方でグローバルカラー上書きを尊重すること、最初の使用後は、Copilot CLI設定ファイルを介して明示的に有効にされない限り、アニメーションを回避すること、支援技術を混乱させる可能性のあるANSI命令を最小限に抑えることです。
「CLIアクセシビリティは研究が不足している」とFellerは述べ、「私たちは、盲目のユーザーと弱視のユーザーの両方から多くを学び、それらの教訓がこのプロジェクトを形作った」と述べています。
このため、アニメーションはオプトインであり、独自のフラグの背後に設置されているため、開発者がデフォルトで目にするものではありません。また、開発者がCLIをスクリーンリーダーモードで実行すると、バナーは自動的にスキップされるため、装飾的な文字やモーションが支援技術に送信されることはありません。
スケーラブルなアーキテクチャの構築
リファクタリングの終わりまでに、チームは以下を持っていました。プレーンテキストとして保存されたフレーム、アニメーション要素、シンプルなマッピングとしてのテーマ、ランタイムカラライゼーションステップ、Ink駆動のタイミングとレンダリング、将来のアニメーションのための保守可能な基盤です。
このパターン、つまりフレームをプレーンテキストとして保存し、セマンティックロールをレイヤー化し、ランタイムでテーマを適用することは、Copilot固有のものではありません。これは、ターミナルUIまたはアニメーションを構築するすべての人にとって再利用可能なアプローチと考えられます。
プロジェクトが明らかにしたこと
「シンプルなASCIIバナー」は、以下のものに変わりました。存在しなかったフレームベースのアニメーションツール、カスタムANSIカラーパレット戦略、新しいInkコンポーネント、保守可能なレンダリングアーキテクチャ、アクセシビリティファーストのCLI設計選択、デザイナーの最初のエンジニアリング貢献、多様なターミナル全体での実世界のテスト、コミュニティからのオープンソース貢献です。
「最もやりがいのある部分は、初めてオープンソースに足を踏み入れたことだった」とFoxlyは述べています。「Copilotを使用して、MVPのASCIIアニメーションツールをascii-motion.appで完全なオープンソースアプリに構築することができた。誰かが私のREADMEのタイプミスを修正してくれて、それが私の一日を作った。」
Fellerが指摘したように、CLIのためのアクセシブルなエクスペリエンスの構築は、まだほとんど探求されていない領域であり、ウェブで利用可能なツーリングと標準にはるかに遅れています。
今日、開発者はすでにFoxlyのASCII Motionツールに貢献しており、Copilot CLIチームはシステムを再構築することなく新しいアニメーションを出荷できます。
これが、ターミナル向けの構築が要求するものです。制約の深い理解、アクセシビリティに関する規律、そして存在しない場所でのツールの発明への意欲です。
まとめ
GitHub Copilot CLIのASCIIアニメーションバナーの開発事例は、ターミナルUIにおけるアニメーション実装が、ウェブやネイティブアプリとは根本的に異なる技術的挑戦を伴うことを示しています。ターミナル環境特有の制約、ANSIカラーコードの不整合、アクセシビリティ要件への対応には、カスタムツールの開発から保守可能なアーキテクチャの構築まで、多岐にわたる工夫が必要でした。デザイナーとエンジニアの協力、AI支援ツールの活用、オープンソースコミュニティへの貢献を通じて、3秒のアニメーションは技術的に洗練された実装として完成しました。この事例は、AI駆動のワークフローがターミナル環境に移行する中で、CLI開発における設計とアクセシビリティの重要性を浮き彫りにしていると言えます。
