yek: リポジトリをLLM向けの単一ファイルに直すRust製CLI
A fast Rust based tool to serialize text-based files in a repository or directory for LLM consumption
ひと目でわかる
- これは何？
- yekは.gitignoreとGit履歴からファイルの重要度を推定し、テキストファイルを1つに連結するRust製ツールである。トークン上限で切り捨てる挙動と、優先順位の付け方が実用上の争点になる。
- 誰に向いている？
- 採用を検討すべきなのは、既存のGitリポジトリをそのままLLMに読ませたいが、除外ルールを自前で書き直したくない開発者である。逆に、バイナリ混在のディレクトリや、ファイルの並び順を完全に自分で制御したい用途には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 78 日前です。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
yekが埋めるのは「どのファイルをLLMに渡すか」の選別コスト
リポジトリをLLMに読ませるとき、作業の大半は連結そのものではなく選別にある。node_modules、ビルド成果物、画像、巨大なロックファイルを除外し、逆に読ませたいソースを漏らさない。yekはこの選別を既定動作として引き受ける。READMEによれば、.gitignoreのルールで不要なファイルを飛ばし、Git履歴からどのファイルが重要かを推測し、バイナリや大きなファイルの除外パターンを追加で推定する。対象はGitリポジトリか、少なくとも.gitignoreを置いているディレクトリである。ファイル名の由来はペルシア語の「1」で、複数ファイルを1つにまとめるという動作に対応している。
出力の並び順はGit履歴の推測に委ねられる
yekの出力はファイルパスを>>>>で区切ったテキストである。READMEの例ではREADME.md、tests/test.rs、src/utils.rs、src/main.rsの順に並ぶ。注目点は並び順そのものだ。READMEは「重要度の高いファイルを出力の最後に回す」と説明しており、その理由としてLLMがコンテキスト後方の内容に注意を払う傾向を挙げている。つまり並び順は可読性のためのアルファベット順ではなく、モデルの注意配分を前提にした設計である。この順序はGit履歴から推測されるため、コミット履歴の薄いリポジトリや、履歴を書き換えたリポジトリでは推測の精度が落ちる。設定ファイルにはGitベースの優先度ブーストを構成する項目があり、推測が外れる場合の調整余地は用意されている。
パイプを検知してストリームに切り替える
既定の動作では、yekは出力を一時ディレクトリ内のファイルに書き出し、そのパスをコンソールに表示する。ただしREADMEは、出力がパイプされている場合はファイルに書かずストリームとして流すと述べている。この分岐があるため、yek src/ | pbcopyのようにそのままクリップボードへ渡せる。逆に、シェルでリダイレクトせずに実行した場合はファイルが作られ、パスだけが表示される。--output-dirで出力先ディレクトリを、--output-nameでファイル名を明示できる。--output-templateを使えば区切り形式を変更でき、既定は「>>>> FILE_PATH\nFILE_CONTENT」である。
トークン上限は「入る分だけ残す」方式である
--tokens 128kのように指定すると、バイト単位ではなくトークン数で上限を扱うモードに切り替わる。READMEの注記によれば、上限に収まらないファイルは削除され、より重要と判断されたファイルを優先して収める。つまり上限を小さく設定すると、内容が切り詰められるのではなく、ファイル単位で丸ごと落ちる。どのファイルが落ちたかは出力からは分からないため、--debugを併用して確認する必要がある。既定の--max-sizeは10MBで、これはバイトモードの値である。ソースコード中心のリポジトリでは10MBは過大で、トークン上限を明示しないまま実行すると、意図したよりも多くのファイルが1つの出力に詰め込まれる。
yek.yamlで既定の除外を上書きする
設定ファイルはプロジェクトルートのyek.yaml、または--config-fileで指定したパスから読まれる。--no-configを付けると読み込みを止める。設定できるのは、ignore_patternsとunignore_patternsによる除外の追加と上書き、max_sizeとtokens、json、debug、そしてファイルの優先順位ルールである。バイナリ拡張子のリストに独自の拡張子を足すこともできる。CLI側にも--ignore-patternsと--unignore-patternsがあり、ビルトインの除外を上書きできる。注意点として、--tree-headerと--tree-onlyはJSON出力と併用できないと明記されている。ディレクトリ構造だけを確認したい場合は--tree-onlyが使える。
向かない場面: 並び順の制御とバイナリ混在
yekの並び順はGit履歴からの推測であり、決定的ではない。同じリポジトリでも履歴の状態によって順序が変わりうる。出力を差分比較したり、プロンプトの一部として固定したい用途では、この非決定性は扱いにくい。また、既定の除外は.gitignoreと推定パターンに依存するため、.gitignoreが整備されていないディレクトリでは除外が効かず、意図しないファイルが混入する。バイナリファイルは拡張子ベースの推定で除外されるが、拡張子が実態と合わないファイルはすり抜ける。--line-numbersを付けると行番号が出力に含まれるが、これはコードの引用位置を示したい場合には有用でも、出力サイズを増やす方向に働く。
代替との違い: repomixは設定主導、yekは履歴主導
同種のツールにrepomixがある。どちらもリポジトリを単一ファイルにまとめるが、重要度の決め方が異なる。yekはGit履歴を優先順位の主要な入力にし、.gitignoreをそのまま尊重する。repomixは設定ファイルと除外パターンを中心に構成を決める傾向があり、並び順や対象の制御を設定側で明示したい場合に向く。判断の分かれ目は、履歴という既存のシグナルを信頼できるかどうかである。コミットが整理されたリポジトリならyekの推測は妥当に働くが、履歴が雑なリポジトリではrepomixのように明示的に列挙する方が安定する。もう一つの違いは出力先の扱いで、yekはパイプ検知でストリームに切り替わる点をREADMEが明示している。
導入と保守のコスト、MITライセンスの範囲
インストールはUnix系ならcurl -fsSL https://azimi.me/yek.sh | bash、Windowsはirm https://azimi.me/yek.ps1 | iex、ソースからならcargo install --path .である。リモートのスクリプトを直接実行する方式なので、実行前に内容を確認するか、cargoでのビルドを選ぶ判断がある。ライセンスはMITで、商用利用や改変、再配布を含む。ただしMITは無保証であり、出力の正確性や除外漏れについて責任を負うものではない。保守面では、v0.25.5が2026年6月29日、v0.25.4が6月6日、v0.25.3が6月2日と、パッチリリースが短い間隔で続いている。0.x系であるため、マイナー更新でCLIオプションや設定キーの挙動が変わる可能性を想定しておく。バージョンを固定したい場合は、インストールスクリプトに任せずcargo install --path .で特定のコミットからビルドする方が追跡しやすい。
編集部の結論
採用を検討すべきなのは、既存のGitリポジトリをそのままLLMに読ませたいが、除外ルールを自前で書き直したくない開発者である。逆に、バイナリ混在のディレクトリや、ファイルの並び順を完全に自分で制御したい用途には向かない。導入前に確認すべきは、--tokensで上限を指定したときにどのファイルが落ちるかを--debugで実際に眺めることと、yek.yamlのpriority_rulesが自分のリポジトリの構成に噛み合うかどうかである。既定の10MBという上限はコード主体のリポジトリでは大きすぎるので、まず--tokens 128kから試すのが現実的だ。
コミュニティノート