Kanazawa.rb meetup #156 に参加しました #kzrb

2025年8月16日に開催されたKanazawa.rb meetup #156に参加しました。ブログで書くのは数年ぶりです。皆さんお久しぶりです。

今回は石川県立図書館の研修室をお借りしての開催でした。写真を取り忘れたので様子は以下リンクからご覧ください。

さて、meetupは13周年を迎えたということでLT大会が行われました。いつにも増して様々なジャンルのトークが繰り広げられ、その中でもLLMや生成AIの話が多めでした。また、困りごとベースで作ったgemについての話もいくつかあり興味深かったです。制作意図が聞けるのは面白い。

興味深かったLT

私が興味深く感じたのはwtnabeさんのRuby de Railway Oriented ProgrammingというLT。Railway Oriented Programmingという概念を知らなかったのですが、関数型プログラミングにおけるエラーハンドリングをきれいに行う方法論のようです。詳しく知りたい方は以下をご覧ください。

fsharpforfunandprofit.com

例えば、APIの処理で、バリデーション、外部API呼び出し、DB更新などの処理をそれぞれ Either[CustomError, T] 的な値を返す関数にして、それを結合して一つのユースケースを表す関数とする。最終的にレスポンスを整える関数を用意して、成功およびエラーはここで適切なレスポンスに変換する、というような構造にするのはどうですか〜というお話。

wtnabeさんの発表を勝手にまとめるとだいたい以下になります。

エラーハンドリングにおいて「例外を処理の分岐や情報の伝播に使いたくない」
Railway Oriented Programmingを適用すると良さそう
dry-operation gemを使ってRubyでも実践できる & モナドの知識が無くても利用できる
ハッピーパスにフォーカスできるので嬉しい

私は仕事でScalaを使う機会が多いゆえエラーを値として扱うのに慣れているというのもあり、これには共感しました。この関数・メソッドは例外を返すかもしれない、というのを考えながら全体を組み立てるのは脳の負荷が高いですし、なによりハッピーパスに集中できることで業務の流れとプログラムが一致しやすくなるのが良いです。

もちろん例外を返す関数やメソッドは普通にあります。大事なのは、これを利用する関数のスコープ内でハンドリングしてエラー値に変換する（例えばDB処理における接続エラーはDAO等でハンドリングした上でエラー値として返す）ことで、これによりスコープを跨ぐ例外の取り扱いを限りなく減らせますね。

私のLT

話は変わって、私は今回「Claude Codeと共に構成図を作る」というお題でLTをしました。頭の中にシステム構成を思い浮かべている状態から同僚に共有するためにある程度整った図を起こしたい、という場面を想定してClaude Code + VSCode + Draw.ioでいい感じにやれないか試してみた話です。発表資料はこちらです。

speakerdeck.com

このLTでのまとめとしては以下の用途ならまあ悪くない、としていました。

脳内イメージを元にした、ある程度整った図の出力
構成を考える上での壁打ち

発表後に、参加者から「フリーハンドで描いた図を写真に撮って、これをClaudeに読み込ませるとどうか？」というフィードバックをもらいました。確かにそうだなと思い後日試してみました。

元ネタはこちら。擦れている部分含めてどう解釈されるのか。

以下のように指示しました。

このやりとりで出力されたファイルをDraw.ioにインポートしたものが以下の図です。

それっぽくも見えますが、コンポーネントが表すものとそれぞれの関係性が異なる部分も見られたのでさらに指示しました。

このやりとりで出力されたファイルをDraw.ioにインポートしたものが以下の図です。

コンポーネントとしては意図したものになりました。AWSというコンテキストが加わり、各コンポーネントが指定された色で塗り分けられるようになりました。ここからもう少し指示を出してAWSアイコンセットを使うこともできましたが、ここでは省略。

以上2つのパターンで図を作成しましたが、当初のユースケース「頭の中にシステム構成を思い浮かべている状態から同僚に共有するためにある程度整った図を起こしたい」においては、私にとってあまり適していないと感じました。その理由として、頭の中のイメージを一度言葉に変換して、それをClaudeなどの生成AIに具現化してもらい成果物を何かしらのツールにインポートする流れが冗長に感じたためです。それならば、最初から自分がDraw.ioなりMiroなりのツールで四角形やふせんのオブジェクトを矢印で繋いだものを作って、同僚には言葉で補足しながら共有する方が速くて楽です。これには同僚の文脈を読み取る能力や、一緒に図を見ながら「これ」「あれ」などの指示代名詞が使えることが影響すると考えられます。ある意味で私の不完全な言語化を同僚が補ってくれているのかもしれません。

一方「構成を考える上での壁打ち」相手としては適しているかもしれません。ただ、これも図だけでは拾いきれない要件や制約があるのでこれらを含めたドキュメントを読み込ませてアドバイスをもらうのが良さそうです。または、要件を先に書き出してそこからコードや図を生成してもらうというやり方の方が生成AIと一緒に進めるときには適しているのかもしれません。