【ITニュース解説】ShellCheck Passed Every File. The Pipeline Was Still Broken.

システムエンジニアを目指す皆さんにとって、日々の開発作業で多くのスクリプトやプログラムを扱うことは珍しくない。特に、複数のスクリプトが連携して一つの大きな処理を実行する「パイプライン」は、ソフトウェア開発の現場で非常に重要な役割を担っている。例えば、プログラムの自動テストやデプロイ（サーバーへの配置）など、一連の作業を自動化するためにスクリプトの連鎖が用いられることが多い。このようなシステムを安定して運用するためには、各スクリプトが正しく動作するだけでなく、それらがお互いをきちんと呼び出し、連携していることが不可欠である。

しかし、従来の多くのコードチェックツール、特に「リンター」と呼ばれるものは、この「連携」部分に盲点があった。リンターとは、ShellCheckやPylintのように、個々のソースコードファイルを開いて、その文法エラーやコーディング規約からの逸脱、潜在的なバグなどを検出するツールである。これらは、単一のファイルの内容が「正しいか？」を判断する上で非常に強力なツールであり、開発者がクリーンで保守しやすいコードを書くのに大いに役立つ。例えば、シェルスクリプトのShellCheckは、存在しないコマンドの呼び出しや構文ミスを教えてくれ、PythonコードのPylintは、未使用の変数や複雑すぎる関数などを指摘する。これらリンターは、継続的インテグレーション（CI）という自動化されたテスト・ビルドプロセスで頻繁に利用され、コード品質の維持に貢献している。

問題は、リンターが「ファイル間の関係性」を見ないことにある。つまり、あるスクリプトファイルが別のスクリプトファイルを呼び出す際、その呼び出し先ファイルが本当に存在しているか、あるいは正しい名前で呼ばれているか、といった点までは確認しないのである。この盲点があると、パイプラインが予期せぬ形で壊れるという事態が発生する。具体例として、デプロイスクリプトが./cleanup.shという名前のスクリプトを呼び出すケースを考える。このcleanup.shが数週間前にclean.shと名前が変更されていたとしても、リンターは呼び出し元のデプロイスクリプト自体に構文エラーがなければ「問題なし」と判断してしまう。その結果、自動化されたパイプラインが実行されると、存在しないファイルを呼び出そうとしてエラーとなり、途中で停止してしまう。このような問題は、AIエージェントが複数のスクリプトを生成して連携させるような場合にも頻繁に発生し、夜中に緊急対応を迫られる原因となることもある。開発者が本当に欲しい情報は、個々のファイルレポートではなく、「どのスクリプトがどのスクリプトを呼び出すのか」「どこで連携が途切れているのか」「意図しない呼び出しの循環（ループ）がないか」といった、システム全体の「地図」なのである。

この問題を解決するために開発されたのが、「script-chain-walk」という新しいツールである。これはPythonで書かれたコマンドラインツールであり、他の特別なライブラリ（依存関係）を必要とせず、Python 3.9以降の標準ライブラリだけで動作する。script-chain-walkの主な目的は、指定されたディレクトリ内のスクリプト間の呼び出し関係を詳細に追跡し、その依存関係グラフを構築することにある。そして、従来のリンターでは見つけられなかった二つの重要な問題、すなわち「壊れたチェーン」と「呼び出しの循環」を特定して報告する。壊れたチェーンとは、呼び出し元のスクリプトが存在しないファイルを呼び出している状態を指し、呼び出しの循環とは、スクリプトAがスクリプトBを呼び出し、スクリプトBがスクリプトCを呼び出し、そしてスクリプトCが再びスクリプトAを呼び出すといったように、無限ループに陥る可能性のある相互呼び出し関係のことである。

script-chain-walkの使い方は非常にシンプルで、pip install script-chain-walkでインストールした後、walkコマンドにチェックしたいスクリプトがあるディレクトリを指定するだけでよい。例えば、walk ./scriptsと実行すると、そのディレクトリ内のスクリプト間の呼び出し関係がテキスト形式で表示される。出力例を見ると、deploy.shがmigrate.pyやnotify.shを呼び出し、さらにmigrate.pyがseed.shを呼び出しているといった階層的な関係が示される。そして、システム全体のスクリプト数、呼び出し関係の数、壊れたチェーンの数、循環の数が集計される。特に重要なのは「BROKEN CHAINS」の項目で、例ではnotify.shの8行目が存在しない./cleanup.shを呼び出していることが具体的に指摘される。これにより、開発者はどのスクリプトのどの行で問題が発生しているのかをすぐに把握し、修正することができる。

このツールには、さらにいくつかの便利なオプションが用意されている。例えば、--format jsonオプションを使えば、機械が読み取りやすいJSON形式で結果を出力できるため、他の自動化ツールとの連携も容易になる。また、--entry deploy.shのように特定のスクリプトを指定することで、そのスクリプトから始まる呼び出しチェーンだけを追跡することも可能だ。そして、CI/CDパイプラインやAIエージェントのガードレール（安全装置）として特に有用なのが--checkオプションである。このオプションを付けて実行し、もし壊れたチェーンや循環が検出された場合、ツールはエラー終了コード（終了ステータス1）を返す。これにより、パイプラインの途中で問題が発見されれば、それ以降の危険な処理が実行されるのを自動的に防ぐことができるのである。

script-chain-walkがどのようにしてスクリプトの呼び出しを検出するのか、その方法も特徴的である。シェルスクリプトの場合、コメントを除去し、行継続を結合しながら各行をトークン（単語や記号）に分割することで、bash foo.shや./foo.sh、source lib.sh、python3 bar.py、exec ./foo.shといった様々な形式の呼び出しを正確に識別する。正規表現の複雑なパターンマッチングに頼らず、より堅牢な方法を用いている。Pythonスクリプトの場合は、Pythonの標準ライブラリであるastモジュールを使って、コードを構文木として解析する。これにより、subprocess.run(...)やos.system(...)、exec(open("other.py").read())、runpy.run_path("other.py")といった、ファイルを実行する様々な関数やメソッドの呼び出しを正確に検出する。検出された呼び出し先ファイルは、まず呼び出し元からの相対パスで解決を試み、見つからなければディレクトリツリー全体から一意のファイル名を持つものを探す。絶対パスでの指定も尊重される。もしファイルが見つからなければ「壊れたチェーン」として報告され、同じ名前のファイルが複数ある場合は「曖昧な呼び出し」として指摘される。呼び出しの循環は、構築された依存関係グラフに対して「深さ優先探索（DFS）」というアルゴリズムを実行することで検出される。

script-chain-walkは、既存の静的解析ツールとは異なる役割を担っている。ShellCheckやPylintが「このファイル自体が正しいか？」という問いに答えるのに対し、script-chain-walkは「このスクリプトの集合体、すなわちシステム全体が互いに正しく連携しているか？」という問いに答える。個々のファイルだけを見るツールでは、例えばa.shがb.pyを呼び出し、b.pyがc.shを呼び出し、さらにc.shがa.shを呼び戻すといったような、ファイル間の複雑な循環参照を検出することは不可能である。スクリプトを自動生成するAIエージェントの利用が増える中で、エージェントが生成したコードが本当に期待通りに連携しているのかを検証することは非常に重要になる。そのような場合に、walk --checkコマンドを使って出力ディレクトリを監査すれば、わずか数十秒で、エージェントが意図せず作成してしまった「死んだ参照」（誰も呼び出さないスクリプトや存在しないスクリプトを呼び出す）や偶発的な再帰呼び出しなどを迅速に特定できるのである。

このscript-chain-walkはオープンソースプロジェクトとしてGitHubで公開されており、PyPIを通じて簡単にインストールして利用できる。依存ライブラリがなく、MITライセンスで提供されているため、様々なプロジェクトで安心して導入できるツールだ。もし自分のプロジェクトでこのツールを使って壊れたチェーンを発見した場合は、開発者にぜひ報告してほしいとのことである。