はじめに

ターミナル向けAIコーディングエージェントoh-my-pi（コマンド名: omp）は、2026年7月時点でGitHub Star数17.5kを集めている新興OSSツールです。目玉機能は「hash-anchored edits」——編集対象の行を丸ごと再送信せず、行ごとの短いコンテンツハッシュ（アンカー）を参照してパッチを当てる仕組みで、ホワイトスペース差異による "string not found" エラーを構造的に防ぐ設計になっています。バージョン16.4.8は2026年7月12日にリリースされたばかりで、記事執筆時点(2026年7月)でも活発に更新が続いています。

この記事で学べること

bun install -g で新興CLIツールを試す際に見落としやすい落とし穴
package.json の engines フィールドを bun がインストール時に検証しない挙動
巨大なミニファイ済みバンドル（12MB超）で構文エラーが起きたときの切り分け方

対象読者

新しいOSS CLIツールを気軽に試したい方
bun / npm の engines フィールドの扱いに疑問を持ったことがある方

前提環境

OS: Linux（クラウド実行環境）
Bun: v1.3.11
Node.js: v22.22.2

TL;DR

bun install -g @oh-my-pi/pi-coding-agent は警告ゼロで成功する
しかし omp --version を実行すると SyntaxError: Unexpected identifier 'z' で即クラッシュする
原因は package.json の "engines": {"bun": ">=1.3.14"} を満たしていなかったこと（手元は1.3.11）
bun はインストール時にこの engines 要件を検証・警告しない
エラーメッセージからは using 宣言（Explicit Resource Management）が怪しく見えるが、実際にその構文だけを抜き出すと単体では問題なく動く——エラー文面が原因を教えてくれないタイプの罠

やったこと

ステップ1: グローバルインストール

READMEに従い、bun でグローバルインストールしました。

bun install -g @oh-my-pi/pi-coding-agent

installed @oh-my-pi/pi-coding-agent@16.4.8 with binaries:
 - omp

260 packages installed [9.76s]

Blocked 2 postinstalls. Run `bun pm -g untrusted` for details.

onnxruntime-node と protobufjs の2件のpostinstallスクリプトがbunのセキュリティ機構でブロックされましたが、これはbunの既定挙動（未信頼スクリプトの自動実行拒否）で異常ではありません。インストール自体は 警告らしい警告もなく 正常終了しました。

ステップ2: 動作確認で即クラッシュ

omp --version すら通りませんでした。

$ omp --version
...(中略・minifyされた大量のコード片が出力される)...
SyntaxError: Unexpected identifier 'z'
      at <parse> (.../dist/cli.js:138:1)
      at native:11:43
note: missing sourcemaps for .../dist/cli.js
note: consider bundling with '--sourcemap' to get unminified traces

Bun v1.3.11 (Linux x64)

--help でも同じエラーで落ちます。バイナリを実行する前段階（構文解析）で失敗しているため、コマンドライン引数を変えても回避できません。

調査

Node.js でも同じ症状

dist/cli.js を直接 Node.js v22.22.2 で読み込ませても、同じ Unexpected identifier 'z' が発生しました。

$ node /root/.bun/install/global/node_modules/@oh-my-pi/pi-coding-agent/dist/cli.js --version
...
SyntaxError: Unexpected identifier 'z'
    at compileSourceTextModule (node:internal/modules/esm/utils:346:16)

エラー箇所をバイトオフセットで特定すると、以下のコードに行き着きました（変数名は元コードのミニファイ後のまま）。

async function Tj4(f,W){
  let{input:Y,stderr:q,allowAbort:Z,allowNonZero:$,...J}=W??{},
      K=typeof Y==="string"?Buffer.from(Y):Y,
      X=K===void 0?J:{...J,stdin:K};
  using z=gB1(f,X);
  return await z.wait({stderr:q,allowAbort:Z,allowNonZero:$})
}

using z = ... はExplicit Resource Management（2025年6月にTC39 Stage 4へ昇格したECMAScript仕様。Symbol.dispose を実装したリソースをブロックスコープで自動破棄する構文）です。Stage 4=仕様として承認済みでも各ランタイムの実装状況は別問題で、手元のNode.js v22.22.2はこの構文をまだサポートしておらず、単体で using 宣言を含むファイルを読ませると同じ Unexpected identifier で失敗することを確認しました。

一方Bunは using をサポート済みで、上記コード片をそのままファイルに切り出して bun で実行すると 問題なく動きました。つまり「using 構文そのもの」が原因ではなく、cli.js 全体（22,458行・12.5MB）の中の 別の何か が真因という状況で、エラーメッセージのスニペット表示は手がかりとしてミスリーディングでした。

真因: `engines` 要件の不一致

package.json を確認すると、実行系の前提条件がはっきり書かれていました。

{
  "version": "16.4.8",
  "engines": { "bun": ">=1.3.14" }
}

手元のBunは 1.3.11。Bun v1.3.11は2026年3月18日リリース、Bun v1.3.14は2026年5月13日リリースで、omp は少なくとも2バージョン新しいBunのビルド出力（バンドラー内部フォーマットやランタイム最適化）に依存していると考えられます。バージョン不足を検証する目的で bun install -g 実行時に engines 由来の警告（npmでいう EBADENGINE 相当）が出るか確認しましたが、bun 1.3.11のグローバルインストールでは出力されませんでした。npmでは engines を満たさないパッケージに警告が出るケースがあるため、この点はツールごとに挙動が異なると理解しておく必要があります。

アップグレードも一筋縄ではいかなかった

原因が判明したので bun upgrade でBun自体を更新しようとしましたが、この検証環境ではGitHub Releasesへの直接アクセスがネットワークポリシーでブロックされており（curl https://github.com/oven-sh/bun/releases/.../bun-linux-x64.zip が403）、公式インストーラー経由のアップグレードは失敗しました。npm経由の bun パッケージも試しましたが、取得されたのはWindows用バイナリ（bun.exe）のみで、Linux用ネイティブバイナリは含まれていませんでした。結果として、この環境では omp を動作可能な状態にするところまでは到達できませんでした。

著者視点の発見ポイント

実際に手を動かして一番驚いたのは、インストールが「成功」と表示された後に、実行できない理由がエラーメッセージからは全く読み取れなかった ことです。SyntaxError: Unexpected identifier 'z' という文面だけを見ると using 構文の互換性問題を疑うのが自然ですが、実際にその部分だけを切り出すとBunでもNode.jsの一部条件でも動作し、原因の特定にミスリードされました。最終的に package.json の engines フィールドを確認して初めてバージョン不一致に気づけたので、新しいCLIツールをインストールしたら、エラーが出る前にまず engines を cat package.json で確認する のが最短ルートだったと言えます。12.5MBのミニファイ済み単一バンドルにはソースマップが同梱されておらず、note: consider bundling with '--sourcemap' という提案もツール利用者側では対応しようがない点も、デバッグの難易度を上げていました。

まとめ

bun install -g の成功は「実行できる」ことを保証しない。engines 要件はインストーラーが検証してくれるとは限らない
ミニファイされた巨大バンドルの構文エラーは、エラー箇所のコード片だけでは真因にたどり着けないことがある
新興ツールを試すときは、READMEの前提条件（今回は「Bun ≥ 1.3.14」）を先に確認するのが結局一番早い
サンドボックス化されたネットワーク環境では、GitHub Releases直配布のバイナリ更新がブロックされるケースがあるため、npmミラー等の代替入手経路もあわせて確認しておくと良い

参考リンク

oh-my-pi（can1357/oh-my-pi） — Star数・バージョン16.4.8・engines要件の引用元
Bun v1.3.11 | Bun Blog — リリース日の引用元
Bun v1.3.14 | Bun Blog — リリース日の引用元
TC39 Explicit Resource Management — using 宣言の仕様（2025年6月Stage 4昇格）