AIによるコード出力への信頼は、コンパイラではなくSaaS事業主と比較するべきではないか

【2025/10/02補足追記】書き方が悪かったため対応関係が曖昧になっていたので追記。対応関係としては、変換層としてのLLM・コンパイラ・SaaS事業主で、SaaS事業主によるSaaS提供では内部の詳細仕様はブラックボックスのまま信頼するので確率的と捉えられるという話でした。以下対応関係のイメージ

• 自然言語 => LLM（もしくはAIエージェント） => コード
• 高級言語 => コンパイラ => アセンブリ
• 何らかの社会課題 => SaaS事業主 => SaaS

---

最近「高級言語 => コンパイラ => アセンブリのように、自然言語 => AI => コードもそのうちコードを見なくて済むようになる」のような話題を見かけることがある。しかしAIによるコード生成は、コンパイラじゃなく、むしろSaaSと比較するべきなのではないかと思った。

まずコンパイラとAIによるコード生成の決定的な違いは、決定論的なのか確率論的なのかという部分だ。コンパイラは入力に対して同じ出力を返すような決定論的な動きをするので、コンパイラに一定の信頼があり高級言語によるコードが正しければアセンブリの出力も必ず正しいと信頼できる。一方でAIによるコード生成は、同じ自然言語に対して毎回違うコードを出力する確率論的な動きをするため、自然言語による入力に対して出力が正しいかどうかは保証がない。

決定論的なのか確率論的なのかの違いがあるため、コンパイラのコード出力への信頼と同じ考え方ではAIのコード出力を信頼できないのではないか。そのためコンパイラとAIによるコード生成は比較しづらいと感じている。

ではコンパイラと違って決定論的に動かないからといって、「そのうちコードを見なくて済むようになる」は達成されないのかというと、そうではないと思う。同じように出力の中身を見ずに挙動だけを信じているものを考えると、AIによる出力はSaaSに近いのではないかと感じている。

SaaSを利用するとき、僕らは実際のコードを見ずに挙動だけ信じている。もしAIによるコード生成の中身を見なくて済むようになるなら、SaaSと同じように信頼できると感じる時ではないか。そう考えると、どのような場合は利用するSaaSを信じるという判断を下しているのかを深掘りすると、どうなれば「そのうちコードを見なくて済むようになる」未来に到達するのかをイメージできるかもしれない。

このように最近僕はAIによるコード生成は、コンパイラじゃなく、むしろSaaSと比較するべきなのではないかと思ってきている。とくに根拠があるわけではないが、最近の自分の考えを述べてみた。

Slack Explorer MCPをStreamable HTTPに対応しました

この記事で紹介したSlack Explorer MCPをStreamable HTTPに対応した。どこかでホストしておけばChatGPTなどからRemote MCP経由で簡単に接続できるようになったので、その使い方を紹介する。

起動方法は以下の通り。

# Streamable HTTPモードで起動（デフォルトポート: 8080）
docker run -i --rm --pull always \
  -e TRANSPORT=http \
  -p 8080:8080 \
  ghcr.io/shibayu36/slack-explorer-mcp:latest

# カスタムポートで起動
docker run -i --rm --pull always \
  -e TRANSPORT=http \
  -e HTTP_PORT=9090 \
  -p 9090:9090 \
  ghcr.io/shibayu36/slack-explorer-mcp:latest

デフォルト設定（ http://localhost:8080 ）で起動した場合、Claude CodeからはMCPサーバーをこのように追加できる。SlackトークンはX-Slack-User-Tokenヘッダー経由で渡す仕組みにした。

claude mcp add \
  --transport http \
  --header "X-Slack-User-Token: xoxp-..." \
  -- slack-explorer-mcp http://localhost:8080/mcp

なぜStreamable HTTP対応したかったか

Streamable HTTP対応をしたかった理由は、非エンジニアでも簡単に使えるようにしたかったからだ。

今までのstdio通信だと、ローカル環境にDockerを用意してコンテナを起動して...という手順が必要だった。これは開発者には簡単だが、そうでない人にとっては少しハードルが高い。

Streamable HTTP対応によって、どこかにホスティングしておけば、ChatGPTなどから接続できるようになる。ローカル環境のセットアップが不要になる。

技術的な裏話: キャッシュとStateful実装

今回の対応では、Statefulな実装にせざるを得なかったのが大変だったので紹介しておく。

まずStreamable HTTPに対応するなら、Statelessに実装する方が楽だ。そうすればLambdaなどserverlessなところへのデプロイも簡単にできる。しかし、Slack Explorer MCPではSlackのユーザー一覧をキャッシュしているためStatelessにはできなかった。

そこで、Statefulな実装とし、session単位でin-memoryでキャッシュ管理することにした。またキャッシュにはexpiredを設け、goroutineで定期的に削除することでメモリリークを防ぐようにした。

どのように実現しているかは、キャッシュ管理をしているuser_repository.goを参考にしてほしい。

まとめ

非エンジニアでも使いやすくするため、Slack Explorer MCPのStreamable HTTP対応をした。キャッシュ周りが大変だったが実現できて良かった。

AIにブログを書かせた方がむしろ理解が深まっている感覚がある

自分がブログ記事を書いている理由の1つは、ブログを書くことで自分の理解が深まるからだ。そのため理解を深めたい内容だったら、AIにブログ記事を書かせるより、自分ですべて書いた方が良いと考えていた。

しかし最近、Claude Codeによる執筆環境を整えた結果、AIにブログを書かせた方が、むしろ自分の理解が深まっているのではと思い始めた。たとえば「経験を積むほどインプット出来ていない感覚になりやすいのではないか」という記事を書いたとき、このような感覚になった。

なぜこのように感じたのか、理由は大きく3つありそうだ。

1. AIがインタビュワーとして機能する。「それってどういうこと？」「具体例は？」といった問いかけによって、自分の中の暗黙知が引き出される
2. 細かい文章表現に気を取られずに、「何を伝えたいか」「話題の繋がりは何か」という構造レベルの思考に集中できる
3. AIがたまに自分の全く想像していなかった話題を生成し、それが逆に新しい発見とつながることがあるから

もちろんこれは、自分の文体を真似てClaude Codeにブログ記事を書かせるという執筆環境を整えたからこそできたことだ。環境を整えてないと結局細かい修正に時間を取られ、構造理解に集中できず、結果的に理解を深める効果はない。

想像と違って、AIに書かせた方が理解が深まることもあるのは意外な発見だった。AIに対する最初の思い込みにとらわれず、いろんなことを試してみたいなと思う。