Rubyセミナー オンラインに登壇します

2026年3月11日(水) 14:00 〜 15:00 に開催される Rubyセミナー オンライン (無料) に登壇します。

www.ruby.or.jp

『RubyでLLMアプリケーション開発を支える基礎技術 [増補改訂版]』というタイトルで、去年の RubyWorld Conference 2025 での登壇内容をアップデートしたコンテンツをお話しします。

この時のスライドは公開済みですが、尺の都合で超特急トークになった上に動画非公開となっています。今回、改めて話す機会を頂きましたので、動きのはやい AI 分野の話のため再度じっくり聞いてみたい方や、Ruby で LLM アプリケーションを作るための基礎について興味のある方など、ぜひお越しください。全国から参加できるオンライン形式です。

ちなみに RubyKaigi 2026 CFP を通過したプロポーザルでは、Ruby x AI がひとつのテーマとなっています。そちらも 30 分という尺の都合がありますので、今回話すような事柄は前提知識として置いたトークになると思います (RubyKaigi 2026 の登壇スライドはまだ何も手をつけていませんが) 。なお、今回の Ruby セミナーは 30 分だと時間が足りない可能性があることをお伝えして 45 分枠になりました。RubyWorld Conference 2025 で話した15枠に対して 3倍の時間が今回です。

実はファーストコンタクトでは、Agentic Coding を含め、 AI を活用したソフトウェア開発というオファーで来ていたのですが、AI 使いこなし術みたいな話になると、そのときの知見ではあまり Ruby 関係ない話になりそうだと判断して上記のようなお話としました。なので、Claude Code なんか毎日使っての知見などありますが、今回そのあたり (Ruby が関係ない文脈になるようなもの) は話さないのかな?たぶん、といったところです。

さておき、Ruby エコシステムにおける AI に関するお話となります。お楽しみに。お申し込みはこちらから。

us02web.zoom.us

それではオンラインでお会いしましょう。

Claude Codeの追い方と現状の設定

自分の Claude Code の追い方と現状の設定です。10人いれば、10人の追い方があると思うので、参考のひとつ程度まで。Claude Code 2.1.55 時点をベースにしています。

TL;DR

これから Claude Code を始める方は、平川本の購入とステータスラインの設定はしておくと良いです。おすすめ。

追い方

最初は習うより慣れろで使っていました。情報はオンデマンドでインターネット検索。いまだと Claude Code について Claude Code に質問すると、Claude Code 専門の claude-code-guide サブエージェント (LLM は haiku) での回答が得られる作りになっている (/agents のエージェント一覧で確認できる) 。

書籍『Claude CodeによるAI駆動開発入門』 (平川本)

そういった我流だとどうしても知識のデコボコが生じるので書籍を読んでおいたのが『Claude CodeによるAI駆動開発入門』だった。

変化の速いジャンルなので、出版から比較的速い段階で読んだ覚えがある。読んで一番良かったなと思うのは、Claude Code への意識が上がったことだった。また、雑に claude コマンドで起動して使っていることが多かったところ、読後は claudeclaude -cclaude -r でのセッションを使い分けをしたり、claude -r で見分けしやすいように /rename を使ったりしている。ちょっとした機能開発だとセッション (コンテキストウィンドウ) と git ブランチと PR がセットにするときがある。一端としてはそんな感じで、コンテキスト操作への意識の高まっている気がする。

/rewind はそれなりに頻度高く使っている。日本語入力だとどうしても入力ミスで途中入力してしまうケースがあって、そういったケースなんかにも使う。最近の Claude Code だと対話だけでなく生成したコードも一緒に巻き戻せるので便利。

そんな感じでそれなりに同僚に薦めていて、10冊近く (以上?) 購入があったと思う。同僚からは「平川本」と命名されて一部でそのような呼称で読んでいる。

平川本は早めに目につけた一冊だったのと、書籍は著者重要であることから、書籍発売に関する著者平川さんの公開動画を見て信頼筋とわかったので購入に進めていた。

jobs.forkwell.com

スライドも公開されています (ありがとうございます) 。出版後も gihyo.jp などでフォローアップされていて丁寧。

gihyo.jp

Claude Code はほぼ毎日アップデートされているので、出版後からそれなりに変化しているもののベースとなる考え方は得られると思います。とはいえ、Claude Code 本体からの差分は小さい方が良いので、Claude Code に興味があるけれどという人はいますぐ買って読んでみるのがおすすめ。例えば ultrathink などはデフォルトの振る舞いになって消えた機能になっています。

平川本以外にも Claude Code の書籍は出版されているものの、他の書籍は単純に読んでいないので、ここでは取り上げません。他の読者に委ねます。

SNS (X) でのウォッチ

Claude Code の開発者である Boris Cherny はもちろんのこと、Claude Code に関する何人かの日本人発信者なんかを X のリストでウォッチしている。動きの速いジャンルなので、エッジをウォッチしている人をウォッチするスタイル。ちなみに以下のようなアカウントを見ておくと結構情報が入ってくる。

書籍は出版時点での情報ベースになるため、ソフトウェアの更新情報を追うのはインターネットの海になる。書籍で足場を固めて、インターネットエッジをキャッチアップしていく古今のスタイルです。

CHANGELOG.md

約束の地とすら言える行き着く先。前述の oikon48 さんがまとめてくれているのは当然便利として、習慣として見ても良いと思う。

github.com

余談ですが、GitHub のイシューなんかは、とんでもない分量が流れています。/feedback スラッシュコマンドは使ったことないですが、何か問題が見つかったらこちらのイシューから報告できます。

github.com

設定

最初に設定についてまとめておくと、とりあえずステータスラインは設定しておくと便利だと思います。

ステータスラインの設定

/statusline スラッシュコマンドから良い感じのものを作ると良いですが、自分はこんな感じの設定を ~/.claude/settings.json にしています。

{
  "statusLine": {
    "type": "command",
    "command": "jq -r '\"CWD: \\(.workspace.current_dir) | Model: \\(.model.display_name)\" + (if .context_window.used_percentage then \" | Context Usage: \\(.context_window.used_percentage)%\" else \"\" end)'"
  },
  ...
}

ステータスラインはこんな感じです。カレントディレクトリ、モデル、コンテキストウィンドウの消費量を表示しています。

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯ Try "how does ..."
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  CWD: /Users/koic/src/github.com/rubocop/rubocop | Model: Opus 4.6 | Context Usage: 37%
  ⏸ plan mode on (shift+tab to cycle)

レビュー用のスラッシュコマンド

コードの質を上げるために AI を使いたい気持ちから作っているものとして、~/.claude/commands/review-last-commit.md としてレビュー用のコマンドを用意しています。そのうちリポジトリ公開するかもしれないので、英文としています。ポイント1つめは $LANG に基づいて対話するようにしているので、いい感じの自然言語で対話できる見立て。

---
Description: Review the last commit.
---

Please follow these steps:

1. Get the hash and message of the last commit with `git log -1 --format="%H %s"`
2. Get the commit summary and list of changed files with `git show --stat HEAD`
3. Get the actual changes with `git diff HEAD~1..HEAD`

Please check the following aspects during the Codex review:

- Commit Message: Clarity and alignment with the change intent
- Code Quality: Readability, naming conventions, code style
- Potential Bugs: Logic errors, unhandled edge cases
- Security: Vulnerabilities (injection, XSS, etc.)
- Performance: Any inefficient operations
- Tests: Whether tests have been added or updated

First, run the review with Claude Code.
Second, run Codex by passing the above instructions as the prompt:

```bash
codex exec --full-auto --sandbox read-only --cd /path/to/project "Replace with prompt"
```

Finally, after cross-checking with the Codex review, provide specific suggestions for any improvements.

IMPORTANT: Responses to this review must be in natural language based on the `$LANG` environment variable.

加えてのポイントとしては、コード生成に使っている Claude Code と、レビューに強い傾向にあると体感している Codex の掛け合わせでクロスチェックのレビューをするようにしています。なお、概ねひとつの変更要求に対してひとつの PR とひとつのコミットで完結する git 履歴の作り方を前提で組んでいます。ふだん使いの Claude Code のままレビューに進むと自身の LLM だから甘さが出るのか、人間の頭脳と同じで LLM クロスレビューする方が効果が高い実感があります。いずれ CodeRabbit CLI なんかも組み合わせてみるかもしれません。従来のセルフレビューなんかに、こういった AI レビューを加えてレビュー観点のブーストを行っています。Claude Code で /review-last-commit と実行すれば、あとは自律的なレビューに進みます。

/review-last-commit

なお、Claude Code だと Skills についてもスラッシュコマンドで呼び出せるので、Skills にしてもいいかもしれないとは思っています。そのうちやるかも。

デフォルトモードをplanモードにしている

基本的に計画を立ててから実行というスタイルなので、デフォルトモードは plan にしています。plan モードにするのを忘れることがあるので、その予防のひとつを兼ねています。

{
  "permissions": {
    "defaultMode": "plan"
  }
}

code.claude.com

あとは、Claude Code の自動更新を latest にしたり、Playwright CLI を設定したりしていますが、今日はこのあたりまで。

とりあえず、これから Claude Code を始める方は、平川本の購入とステータスラインの設定はしておくと良いです。これらはおすすめ。

『ChatGPTはどのように動いているのか?』を読んだ

3連休の隙間で『ChatGPTはどのように動いているのか?』を読んだ。

ChatGPT としているものの、話としてはベクトル、行列、Embedding の解説をとおして、現代 LLM の基礎となる Transformer アーキテクチャの仕組みを理解するというものだった。ChatGPT の基盤となっている GPT (Generative Pre-trained Transformer) モデルのベースとなるアーキテクチャなのはそうとして、タイトルに ChatGPT を含めているのはマーケットを意識したものかも?ともあれ、より通念的な理解から GPT について学べるので作りとして期待どおり。

推測はさておき、本書は LLM におけるベクトルがどのように動いているかのイメージがつきやすくなる構成になっていると思う。そういった意味で、本書ではベクトルが主役。

書籍の文中にも示されているように、ちょっと込み入っているところを流すスタイルであれば、さっと読み物形式で読めると思うので、『Attention Is All You Need』 の有名な以下の図が何を言っているのかの全体感を知りたい人なんかは読んでみると良さそう。

https://upload.wikimedia.org/wikipedia/commons/8/8f/The-Transformer-model-architecture.png

(https://ja.wikipedia.org/wiki/Attention_Is_All_You_Need からの引用図)

識者は知ってのとおり、左側のエンコーダと右側のデコーダのうち GPT はデコーダのみをもちいているアーキテクチャとなっていますが、その理由についても軽く触れられています。

個人的には5章の LLM (Large Language Model) から LMM (Large Multimodal Model) への話と、おまけ的なトピックとなっている 7章の Grokking に関する話が面白かった。

誤差逆伝播法まわりの動きについては、以前読んだ『数式なしでわかるAIのしくみ』の方が説明が深いかもしれないので、掛け合わせで読んでみて良いかもしれない。

koic.hatenablog.com

どちらを先に読むと良さそうかでいうと、出版順序は前後するものの、いまのところ大きく話が変わらない Transformer アーキテクチャをテーマにしている点から、初手としては『ChatGPTはどのように動いているのか?』の方が難易度的にも読みやすいと思う。

git-wtを導入した

git-wt を導入したので、メモとして導入ログを記しておく。

github.com

導入動機

Agentic Coding によってにわかに脚光を浴びている git worktree だけれど、実際のところワークツリーディレクトリどこに置くの?といった話などちょっとした敷居がある。特に ghq ユーザーにとっては、ghq root (e.g, ~/src, ~/ghq) のディレクトリの直下にワークツリーを置くような運用だと、いかにも管理がしづらいのでどうするかという問題があった。

今回 songmu さんによる以下の神機能が入ったということで、個人的には git-wt が顧客が本当に求めていたものになったので導入することにした。

github.com

正直 ghq root 直下にリポジトリと並んでワークツリーディレクトリがあると、理由あってワークツリーディレクトリを削除する時にかなりハラハラすることになる。間違ったら .git ディレクトリごとリポジトリを消すことになるので壊滅的な打撃を被ることになる (手に汗握る) 。ワークツリーディレクトリが、リポジトリ配下の管理になるとリポジトリのルートディレクトリに移動して rm -rf .worktrees などすれば良いので、かなり精神的に楽。

じゃあ、リポジトリ配下にするとなるとそれはそれで一手間面倒だなというのがあったのを解決したのが上記の PR で、これは完全にアイデアの勝利というか、本当にありがとうございますというものだった。songmu さんはすごい人。

自分的にはこれでワークツリーディレクトリをどこに置くか問題に終止符が打たれたと思っていて、peco などの ghq root からのリポジトリ選択のフィルタリングツールにもワークツリーディレクトリが入らないし、いいことしかない。git-wt では、このような位置にワークツリーディレクトリのデフォルトを変更しようかという動きがあるので、意見のある人はコメントをしてみると良いと思う。

github.com

導入ログ

ghq + zsh + peco を使っている自分の設定手順を書いておく。なお、基本は git-wt の README に従えば、欲しい情報は記されていると思います。

インストール

むしろ安定版を選ぶ理由が現時点でなかったので、私は最新を取得しています。お好みで。

$ go install github.com/k1LoW/git-wt@latest

設定

まず、自分はワークツリーディレクトリは .worktrees という名前で~/.gitconfig へのグローバル設定することにした。リポジトリルート直下に置くワークツリーディレクトリ名は .wt というのも git-wt からの部分引用命名でそれっぽくあるものの、ぱっと見でわかりやすさを狙っている。コンフリクトしたらそのとき考える。なおこのあたりは上述のイシューが参考になると思う。

$ git config --global wt.basedir ".worktrees"

次に、~/.zshrc あるいはそこから読み込まれるファイルに以下を追加する。

eval "$(git wt --init zsh)"

最後に peco を使ったフィルタリングを wt コマンドとしてできるように以下も設定する。

wt() {
  git wt "$(git wt | tail -n +2 | peco | awk '{print $(NF-1)}')"
}

こんな感じで、git wt branch_name とすると良い感じに働くようになる。削除時は git wt -d branch_name あるいは git wt -D branch_name を使う。

Agentic Coding で並行作業する際に、同一リポジトリで作業が被った際に、git worktree の細々が面倒なので別のリポジトリの作業でもやっておくかという運用でカバーへの良いカウンターになった。

songmu さんがメンテナンスしている ghq と、k1LoW さんが作っている git-wt のコラボレーションは OSS のハートフルな相互作用で見ていて面白かったです。素敵なセンスの合作をありがとうございます!

MCPがApache 2.0へのライセンス移行を開始した

先月 MCP が Linux Foundation 傘下になった流れで、MCP ならびに管轄リポジトリについて Apache 2.0 へのライセンス移行が行われた。

github.com

MCP Ruby SDK についても MIT から Apache 2.0 へのライセンス移行となっている。

github.com

もう少し今回のライセンスについて説明を足すと、従来のコードは依然として MIT 扱いともなりえて、新たなコードは Apache 2.0 ライセンスという扱いらしい (上記 PR のライセンス更新より抜粋) 。

The MCP project is undergoing a licensing transition from the MIT License to the Apache License, Version 2.0 ("Apache-2.0"). All new code and specification contributions to the project are licensed under Apache-2.0. Documentation contributions (excluding specifications) are licensed under CC-BY-4.0.

Contributions for which relicensing consent has been obtained are licensed under Apache-2.0. Contributions made by authors who originally licensed their work under the MIT License and who have not yet granted explicit permission to relicense remain licensed under the MIT License.

No rights beyond those granted by the applicable original license are conveyed for such contributions.

Ruby のようにデュアルライセンスというのもひとつだと思うものの、そのあたり Anthropic なんかが法務なんかと色々と考えたんだろうと思っている。

影響のある人はそれほどいない気がしますが、片隅にでもご留意ください。

MCP Ruby SDK 0.5.0をリリースした

MCP Ruby SDK 0.5.0 をリリースした。

github.com

詳細はリリースノートからのリンクを参照として、サーバー側の SDK への主な更新は以下です。

  • プロトコルバージョン 2025-11-25 に一部追随した
  • Streamable HTTP での stateless モードをサポートした
  • Tool のレスポンスで structuredContent をサポートした
  • Ruby のランタイムバージョンのサポートを Ruby 2.7 以上とした (以前は Ruby 3.2 以上をサポート)
  • Tool の名前についてバリデーションを行うようにした

クライアント側にも prompt/listprompt/get のサポートならびに、Accept ヘッダーのバリデーションが追加されています。

何か問題があればイシューにてお知らせください。

github.com

test-queue 0.12.0をリリースした

test-queue 0.12.0 をリリースした。

github.com

前回の 0.11.0 のリリースから約2年ぶりのリリースとなる。今回のリリースは、同僚の S.H. が Minitest 6 対応をしてくれたものになる。

github.com

Minitest 6 で test-queue を使っている人はアップデートしてみてください。

なお、Rails 8.1 系で Minitest 6 へのアップグレードでのワークアラウンドの必要性が気になっている人は、先日リリースされた Rails 8.1.2 へのアップグレードでワークアラウンドなしで解決できるようになりました。