stdio は standard input / standard output の略で、標準入力と標準出力を使ってプロセス間でやり取りする方法です。
ローカルで起動したプログラム同士をつなぐときによく使われます。
まず押さえたいポイント
- 同じマシン上のプロセス間通信でよく使う
- ネットワーク越しではなく、直接起動したプログラム同士のやり取りに向く
- MCP ではローカルサーバー接続の代表例
どんな場面で使うか
どんなふうに理解するとよいか
手元のアプリが、手元の別プログラムを起動して直接話す方式 と考えると分かりやすいです。
MCP では、クライアントがサーバープロセスを起動し、その標準入出力へ JSON-RPC メッセージを書いてやり取りします。
なぜ MCP のようなツール連携で選ばれるのか
外部プロセスと通信する方法は他にもあります（HTTPを立てる、ソケットを開く、ファイルを介す）。それでも標準入出力が選ばれるのは、接続の準備が要らないからです。
| 方式 | 事前に必要なもの | 権限・到達範囲 |
|---|---|---|
| 標準入出力 | 相手を起動するだけ | 起動した親子の間だけ |
| HTTP | ポートを開く・URLを決める | ネットワークから届きうる |
| Unixソケット | パスを決める・後片付け | 同じマシンのファイル権限に依存 |
ポートを開かないということは、そのプロセスが外から叩かれる心配が無いということです。ローカルで動かすツール連携では、この性質がそのまま安全側に働きます。逆に、別マシンから使いたい・複数から同時に使いたい場合は標準入出力では足りず、HTTP 側の仕組みが必要になります。
つまずきやすいのは「出力の混線」
標準入出力を通信路として使うとき、いちばん多い事故がログを標準出力に書いてしまうことです。相手はそこを構造化データの通り道として読んでいるので、デバッグ用の1行を混ぜただけで解析が壊れます。
- ログや進捗は標準エラー出力（stderr）へ出す
- ライブラリが勝手に標準出力へ出していないか確認する
- バッファリングで送信が遅れることがある。行単位で流す設定にするか、明示的に流し切る
押さえておきたい注意点
stdout に余計な文字列を出すとプロトコルが壊れやすいです。
ログは stderr 側へ出す、標準出力には正しいメッセージだけを流す、という考え方が大事です。
実務で見るポイント
- ローカル利用ではかなり扱いやすい
- 余計なログ出力で通信を壊さないようにする
- リモート公開や多人数利用には別方式の方が向くことが多い