みなさん、こんにちは。
以前、Haiku OSでAIによるコード支援を実現するためにGemini CLIを動かす方法を紹介しました。
記事公開後、私自身もしばらく運用してみたのですが、正直なところGeminiの無料版ではトークン制限にすぐ引っかかってしまい、日々の開発にガシガシ使うには少し物足りないのが現実でした。
もちろんGeminiに課金する選択肢もありましたが、私のメインのAIエージェントはGitHub Copilot CLIです。メイン環境であるXubuntu 22.04 LTSでGitHub Copilot CLI を使った開発の快適さを知ってしまうと、Geminiに追加で課金するのは、コスト面でもワークフローの統一感という面でも、あまり合理的ではありません。そのため、Haiku OSでAIエージェントを使うという野望は久しく興味の対象から外れてしまっていました。
しかし、先日、久しぶりにHaiku OS を最新のナイトリービルドを使ってセットアップしてみると、できることが増えており、Haiku OSに対する興味が復活してきたのです。
こうなると、沸き上がってくるのはエンジニアとしての根源的な欲求です。
「使い慣れたGitHub Copilotを、このHaiku OS上でも自在に操りたい！」
今回は、Haiku上でいかにしてCopilot CLIを動作させるかという目的を達成するため、2026年5月時点の最新ナイトリービルドが抱える「壁」を、古き良き「枯れた技術」で乗り越えた試行錯誤の記録を共有します。
立ちはだかる壁 – Node.js 22の非対応
最初のハードルは、GitHub Copilot CLIの動作要件です。現在のバージョンではNode.js 22以降を必須とします。
しかし、Haiku OSのリポジトリやビルド環境では、Node.js 20までしか対応していません。IT業界に身を置いていると、こうした「依存関係の壁」に時々遭遇しますが、Haikuのような独自進化を遂げるOSではこれが日常茶飯事です。
結論から言えば、Copilot CLIをHaiku OS上で直接動かすのは現時点では不可能です。
では、方法は全くないかといえば、そうでもありません。
「Haikuで動かないなら、すでに動作環境が整っているLinux（WSL）側でCopilot CLIを動かし、そこからHaikuへリモート接続して操作させればいいのではないか？」
昨今話題のOpenClawでも多用される、リモート操作の手法を使えばいいわけです。
SSHの挫折 – ナイトリービルドに潜む「暗号化バグ」
遠隔操作といえばSSHが定石です。HaikuにはSSHサーバーが標準で内蔵されており、設定ファイルを少し弄るだけで有効化できるはずでした。
ところが、ここで予期せぬ致命的な事態が発生します。2026年5月時点のナイトリービルド版Haikuにおいて、暗号化系の認証に根深いバグが潜んでいるようなのです。
具体的には、以下のような症状に見舞われました。
/boot/system/settings/ssh/sshd_configにPasswordAuthentication yesを設定しても、外部からのログインがことごとく拒絶される。/boot/system/settings/etc/shadowのパスワードハッシュは正しいにもかかわらず、認証が通らない。- SFTPによるファイル転送も同様に失敗し、さらには公開鍵認証までもが動作不安に陥る。
調査を進めた結果、暗号化を伴う認証処理そのものがHaiku側で壊れている可能性が高いという結論に達しました。最新のナイトリービルドを追いかけるギークの宿命とはいえ、これではAIエージェントを接続することができません。
救世主は「Telnet」
万策尽きたかと思われたとき、ふと思いついたのが、暗号化を一切使わない古のプロトコル、Telnetでした。 試してみると、驚くほどあっさりと、そして安定して動作したのです。
「2026年にTelnetか？」と思われるかもしれませんが、LAN内での利用に限定すれば、このシンプルさはむしろメリットとなります。暗号化バグという現代的な壁を、歴史的なプロトコルが打ち破った瞬間でした。
expectによる自動ログインの実装
Telnetで繋がることは確認できましたが、新たな問題が浮上します。Copilot CLI（AI）にHaikuを操作させる際、毎回パスワードを手入力させるわけにはいきません。
また、対話プロンプトの中でパスワードをAIに直接渡してしまうのは、セキュリティ意識の高い技術者として許容できません。パスワードがAIの学習データやクラウド側のログに送信されるリスクを回避する必要があります。
そこで、ログインシーケンスをカプセル化するために、古くからの自動化ツールであるexpectを導入しました。
Linux/WSL側での準備
まずは、ホストとなるLinux側（Copilotが動いている側）にexpectをインストールします。
sudo apt install expect
次に、自動ログインスクリプト haiku-login.exp を作成します。
#!/usr/bin/expect
# 接続先HaikuのローカルIPアドレスを指定
spawn telnet 192.168.xxx.xxx
expect "login:"
send "user\r"
expect "Password:"
send "YOURPASS\r"
interact
※Haiku OS のデフォルトユーザーはuserです。Haiku OS ではデフォルトの状態だとパスワードが設定されていません。ターミナルを開いて passwd コマンドを実行することによりパスワードが設定できます。設定したパスワードをYOURPASSのかわりに入力してください。
このスクリプトは、自分だけが読み書き実行できるように権限を厳格に設定しておきます（chmod 700）。 これにより、Copilot（AI）には「Haikuへ接続する」という動作だけを見せ、パスワードそのものは必要以上に公開しないまま、安全にログインを自動化できます。
Copilot CLIへのカスタムコマンド登録
仕上げに、Copilot CLIからこのスクリプトを「自然な言葉」で呼び出せるように設定します。 ~/.config/github-copilot/cli/commands.json に、独自のエイリアスを追加しましょう。
{
"haikuに接続して": {
"run": "~/haiku-login.exp"
}
}
これで、AIとHaikuを繋ぐブリッジが完成しました。
最終動作 – AIがHaikuのネイティブ環境を操る
実際に動かしてみましょう。WSL2のターミナルで copilot を起動し、こう指示を出します。
「haikuに接続して」
すると、バックグラウンドでexpectが起動してTelnetのログインを代行し、Haikuのシェルへと橋渡しをしてくれます。
Copilot側からは、今いる場所がLinuxなのかHaikuなのかを意識することなく、Haikuのファイルシステム（BFS）に対して直接コマンドを発行し、コードを生成・配置できるようになるわけです。
Haiku OSは依然としてアプリケーションが少ないOSですが、こうしてAIにコードを書いてもらい、その場でビルドして実行まで任せられる環境が整ったことは、開発効率を飛躍的に高めてくれます。
まとめ – 今回の構成図
最終的なシステム構成を整理すると、以下のようになります。
- ホスト: Linux/WSL
→ 最新のNode.js環境でGitHub Copilot CLIが安定動作。 - 連携層
→expectスクリプトが、パスワードを隠蔽しつつTelnetログインを代行。 - ターゲット：Haiku OS
→ 暗号化バグの影響を受けないTelnet経由で、AIからのネイティブコマンドを直接実行。
最新鋭のAIを、あえて「枯れた技術」であるTelnetとexpectで接続する。この、少し皮肉の効いたアプローチこそがHaikuのようなマイナーOSを操る醍醐味かもしれません。ちなみにこの手法は、最新のNode.jsを動かせない他のレガシーシステムや独自OSにも応用できるはずです。
この「リモートAI操作環境」を構築して、皆でHaiku OSでの開発を加速させていきましょう！
本日も最後までお読みいただきありがとうございました。
それでは、よいHaiku OSライフを！
ピンバック: Haiku OS × GitHub Copilot 移植実録 ― AIの力を借りてLinux用動画管理アプリを数十分でHaikuへ移植する - ビューローみかみ