「あの人も読んでる」略して「も読」。さまざまな寄稿者が最近気になった情報や話題をシェアする企画です。他のテックな人たちがどんな情報を追っているのか、ちょっと覗いてみませんか?
こんにちは、syumaiです。本日より、こちらの #も読
の連載を担当させていただきます。
主な技術領域はGo、TypeScript、JavaScriptですが、直近では、開発ツールとしての生成AIに関心があるので、その辺りの話題も多くなります。
DeepWiki
生成AIを活用した開発関連ツールとして直近特に盛り上がったのは、Devinを開発しているCognitionがリリースした、DeepWikiというサービスです。
DeepWikiとは
DeepWikiは、GitHubの公開リポジトリのソースコードを解析し、その詳細な解説をWiki形式で表示してくれるサービスです。
使い方は非常に簡単で、GitHubリポジトリのURLの github.com
の部分を deepwiki.com
に差し替えて、インデックス作成のリクエストを送るだけです。
インデックスの作成には10分程度かかりますが、既にインデックス作成が完了しているリポジトリについては、すぐに閲覧が可能です。microsoft/vscodeの例を見ると、どういった内容のドキュメントが生成されるか、イメージがつきやすいと思います。
このサービスが大きな話題となった理由は、出力される解説の品質の高さです。単に文字情報で解説を出力するだけでなく、アーキテクチャや処理シーケンスを表す図まで出力されます。解析にはソースコードを使用しているので、ドキュメンテーションが行われていないような機能に対しても、詳細な解説が出力されます。
筆者の作成しているライブラリでも、ドキュメンテーションが十分でない機能の完璧なシーケンス図が出力されたので非常に驚きました。
知人のソフトウェアエンジニアの方々も、筆者と同じようにDeepWikiの出力の品質の高さに感銘を受けていたので、パッと見のインパクトだけでない、価値のある解析を行うことのできるサービスだという感覚があります。
DeepWiki / DevinのWikiの使い方
DeepWikiは、よくある生成AIのチャットのような形式で質問を行う使い方もできます。リポジトリ内の詳しく知りたい機能について質問を行うと、ソースコード内の具体的な箇所へのリンク付きで回答してくれます。
非公開リポジトリについては、DevinのWiki機能を使うことで、同様の体験が得られます。と言うより、DeepWikiは、どうやらDevinのWiki機能のアピールのために公開されたサービスのように見えます。
公開リポジトリ (DeepWiki) については、以下のような使い方ができるでしょう。
- OSSのコードリーディングの補助
- OSSへ貢献したいときの、必要な修正箇所の調査
- 自分の開発しているOSSのドキュメントの生成
非公開リポジトリ (DevinのWiki) については、以下のような使い方ができるでしょう。
- 新しく配属されたチームのコードベースへのキャッチアップ
- バグや障害が発生したときの調査
- ユーザーからの問い合わせ対応時の調査
このような検討をしてみると、業務活用のユースケースが多いのは、DeepWikiよりも、むしろDevinのWikiの方だと想像できます。
DeepWiki / DevinのWikiについてのまとめ
Devinは、これまでコーディングエージェントとしての側面が目立っていましたが、今回のDeepWikiのリリースによって、その情報整理・収集能力の高さをうまくアピールできたのではないかと思います。
DeepWikiは、2025年4月末時点では、全て無料で使うことができますが、(憶測ですが)長期的には宣伝効果に見合わないであろうコストがかかっているように見えるので、有料プロダクトであるDevinのアピールという面で一定の成果を出したら、クローズされる可能性もあると思います。
生成AIの可能性を感じる非常に興味深いプロダクトなので、なるべく早いうちに試してみることをおすすめします。気に入った方は、有料プロダクトのDevinも検討してもよいかもしれません。
Codex CLI
ほかに大きな話題になったのは、ChatGPTを開発するOpenAIのリリースした、Codex CLIです。
https://github.com/openai/codex
Codex CLIとは
Codex CLIは、ターミナル上で動作するコーディングエージェントです。例えばターミナル上からCodex CLIを呼び出して、以下のように指示するだけで、自動でアプリケーションの開発が行われます。
codex --approval-mode full-auto "create the fanciest todo-list app"
Codex CLIのREADMEのQuickstartより引用した例
先行事例としては、OpenAIの競合であるAnthropicの開発しているClaude Codeがあります。
Codex CLIが話題となった理由は、何よりOSSとして公開されたことです。ライセンスはApache License 2.0で、これは一般的なOSSのライセンスであり、商用利用や改変も許可されています。
競合のClaude Codeがコードを公開していないことと対照的であるとして話題になりました。Claude CodeはGitHubリポジトリ自体は存在していますが、2025年4月末現在、そこにコードは含まれていません。
更に、リリース当初は生成AIのプロバイダとしてOpenAI (ChatGPT) しか使えなかったものが、リリース1週間程度で、他のプロバイダにも対応したことで再び話題になりました。
例えば、GeminiやDeepSeek、Grokに対応していますし、OpenRouterが使えるので、これを経由してさまざまなプロバイダを利用可能です。ローカルLLMを使いたければ、Ollamaを使うことができます。
こうしたプロバイダの開放も、Codex CLIのオープン戦略を強く印象付ける動きとなっています。
これは筆者の憶測ですが、OSSとして公開している以上、有力なForkが現れて、そこで外部プロバイダへの対応が行われる可能性もあったので、外部コントリビュータによる開発貢献をなるべくCodex CLI本体に寄せる目的もあったのかもしれません。
Codex CLIの使い方
Codex CLIは、基本的には対話的に開発を行うコーディングエージェントとなります。
対話式のUIが不要な場合は、 -q
フラグを付けることで有効化される quiet mode
があります。
また、Codex CLIのexamplesディレクトリを見ると、Codex CLIに行わせたい定型業務を task.yaml
というファイルに定義して、繰り返し実行できるようにする使い方も想定していることがわかります。
恐縮ながら、筆者もまだあまり試せていないので、詳しく知りたい方はCodex CLIのREADMEを参考にしてください。
Sandbox機構
その他に気になったこととしては、Codex CLIの利用するSandbox機構があります。
Codex CLIは、macOS上で外部コマンドを起動するときに、 Apple Seatbelt という機構を使用することが書かれています。例えば、Codex CLI経由で curl
などのコマンドを実行するとき、デフォルトではその外部へのネットワークアクセスは失敗します。
このApple Seatbeltという機構は、多くの人にとって聞き馴染みのないもので、筆者もこれが一体何なのか気になったので、詳しく調べて記事にしました。もし興味があればこちらをご覧ください。
Linux環境ではSandbox機構を利用しないので、Dockerを使うことが推奨されています。Dockerコンテナ内でCodex CLIを起動する具体例として、run_in_container.shというシェルスクリプトが示されています。
Codex Open Source Fund
OpenAIは、Codex CLIやその他のOpenAIのモデルを使用したオープンソースのプロジェクトに対して支援を行うための100万ドルのファンド、Codex Open Source Fundを立ち上げたとのことです。
最大で$25,000のAPIクレジットの支援を受けられるとのことで、趣味プロダクトの開発のために懐を痛めずに済む(オープンソースであれば、業務での開発についても支援があるかもしれません)ので、興味のある方は申し込んでみてはいかがでしょうか?
Go公式のMCPライブラリの開発状況
4月初旬に、GoチームがMCPのSDKを開発しようとしていると発言していたことが話題になりました。 その実装が順調に進んでいるようで、全貌が明らかになりつつあります。
https://pkg.go.dev/golang.org/x/tools@v0.32.1-0.20250425163951-ffe579ab5769/internal/mcp
golang.org/x/toolsのinternal package配下での開発であり、まだ使える状態にはなっていないですが、protocol packageを分離して、親のmcp packageがそれを使うといった構成になっていることがわかります。
GoでMCPサーバーを開発するときのデファクトスタンダードは、現状github.com/mark3labs/mcp-goとなりますが、Go公式のMCPライブラリが完成した暁には、そちらへの置き換えが進むことが想像できます。 開発の動向が気になる方は、toolsリポジトリへのChange Listをウォッチしておくといいかもしれません。
Biomeにexhaustiveness of switch casesのlint対応が入りそうな話
TypeScript関連の話題を一つ紹介します。
既存のJavaScript / TypeScriptのformatter / linterを置き換えるRust製ツールチェーンとして開発されているBiomeに、ついにexhaustiveness of switch casesのlintルールの実装が入ろうとしています。
2025年4月2日に、BiomeがVercelと提携して型推論を改善するという記事が出ていましたが、ここで話題に登っていた型情報を使ったlintルールの実装が、着実に進んでいるものと思います。
個人的には、ESLint (typescript-eslint) からBiomeに乗り換えられなかった最も大きな理由が、型情報を使ったlintがほとんどできなかったことだと思っているので、今後数ヶ月でこの状況が一気に変わっていきそうです。CIでlintにかけている時間が一気に短縮されるはずなので、非常に期待しています。
気になる本
こちらの本を買いました。
『型システムのしくみ ― TypeScriptで実装しながら学ぶ型とプログラミング言語』
まだ読めていないですが、Rubyの静的型解析ツールであるTypeProfの開発を行っているmametterさんが書かれた本ということで、読むのを楽しみにしています。
最後に
ややとりとめのない内容となってしまいましたが、直近特に気になっている話題は以上となります。
今回は、大きなプロダクトが複数リリースされていたこともあり、ややボリューミーな内容になってしまいましたが、次回以降はもう少し小粒な話題を中心に紹介していければと思います。
また次回もよろしくお願いします!