どうも、マイクです。おはようございます。
一〇月七日、水曜日の朝七時を回りました。
ここからの時間は「zenncast」、Zennのトレンド記事をゆるっと紹介していきます。コーヒー片手に、通勤通学のおともに、のんびり聞いていってください。
今日はZennで話題になっている記事を、ぜんぶで五本、ご紹介していきます。技術の学び方からAWS、データ基盤、ゲームAI、そしてClaude Codeの活用まで、かなりバラエティ豊かなラインナップです。
さあ、それではさっそく、一本目からいってみましょう。
。。。。
まず一つ目は、「一〇年前のJava環境をDockerでわざわざ再現してみた」という、ちょっとマニアックだけど熱い記事です。
今って、AIがコードを自動生成してくれて、環境構築もググればだいたい答えが出てきちゃう時代ですよね。それ自体は便利なんですけど、その裏で「失敗しながら手を動かして学ぶ機会」が失われてるんじゃないか、っていう問題意識からスタートしています。
筆者は、あえて一〇年前レベルのJava環境、具体的には、センターオーエスのファイブ、Javaファイブ、トムキャットシックス、そしてSeasarツーという構成を、Docker上に再現していきます。
もちろんスムーズにはいかなくて、まずはセンターオーエスファイブのヤムレポジトリがもう死んでいる問題にぶつかります。さらに、古いOpenSSLでは新しいTLSと握手できないとか、三二ビットと六四ビットのパッケージが競合するとか、日本語が文字化けするとか、実際にありがちなエラーが次々に出てくるんですね。
この記事がおもしろいのは、そこを「はい、答えコレです」で飛ばさないところです。
なぜレポジトリにアクセスできないのか、なぜTLSで握手に失敗するのか、ログやエラーメッセージを手がかりにしながら、「じゃあレポジトリをこう切り替えてみよう」「この設定を変えてみよう」と、仮説を立てて一個ずつつぶしていくプロセスを丁寧に追っています。
環境が整ったあとは、SeasarツーとSAStrutsを使って、シンプルなHello Worldアプリを作ります。まずはトムキャット単体で動作確認して、そのあとApacheからAJPでつなげていく。
この流れの中で、「まずは一番近いところから疎通を取る」とか、「エラーメッセージを読んで、そこから自分に足りない知識を洗い出す」といった、学習の“勘どころ”を体験させようとしているんですね。
筆者が強調しているのは、AIに「答えだけ」を聞かないこと。
「なぜその答えなのか」「自分に足りない前提は何なのか」を問い続けることが、これからの開発者にはすごく大事だと。
ブラウザにHello Worldが出るまでの地道な試行錯誤こそが、実は一番の学びなんだよ、というメッセージがこもった記事でした。
。。。。
続いて二本目は、AWS EC2まわりの、かなり実務的なノウハウです。
最近、EC2を起動しようとすると「InsufficientInstanceCapacity」、つまりキャパシティ不足のエラーが出ること、増えてませんか？ この記事の筆者も同じ状況にあって、特に検証環境で、朝の自動起動が失敗してしまうのが課題になっていました。
本番環境なら、例えばTエイトアイ世代のインスタンスにすぐ移行する、みたいな選択肢もありますが、検証環境だとそう簡単に変えられないケースも多いですよね。
そこで筆者が考えたのが、「朝の自動起動の前後だけ、オンデマンドキャパシティ予約を自動で取る仕組み」です。
キャパシティ予約には、「すぐ開始」と「将来日付」の二種類があります。
ただ、将来日付のほうは条件が厳しくて、開始まで一四日以上あける必要がある上に、三二ブイシーピーユー以上じゃないとダメなんですね。
筆者のケースでは、ティースリー・ミディアムを九台、つまり一八ブイシーピーユーぶんを、朝の数十分だけ確保したい。でもこれは将来日付の条件を満たさない。
なので、毎朝「すぐ開始」のキャパシティ予約を作って、インスタンス起動が終わったらすぐ取り消す、という方針を取っています。
この自動化の構成がまたスマートで、EventBridge SchedulerからStep Functionsを起動して、「予約を作成する → 取り消し予定時刻までWaitする → 予約を取り消す」という一連の流れを、一本のステートマシンで完結させています。
Step FunctionsはEC2のAPIを直接呼べるので、Lambda関数を書いたり、ランタイムを管理したりする必要がありません。待機中も料金はほとんどかからないので、コスト面でも優秀です。
一点注意なのが、キャパシティが足りないとき、AWS側で「空くまで待ってくれる」という挙動にはならないこと。
そこで筆者は、Step Functions側で一分おきにリトライするロジックを入れて、`EndDate`は「どうしても取り消しに失敗したときの保険」としてだけ使っています。
また、検証環境という性質もあって、祝日判定までは行わず、「休みの日にちょっと余分に予約が走っちゃうくらいは許容する」という割り切りで運用しているのもポイントです。
毎朝の自動起動が安定しない、でも大がかりな構成変更は難しい、というチームにはかなり現実的なヒントになる記事でした。
。。。。
三本目は、データ基盤まわり、OneLakeのショートカットの挙動についての解説です。
OneLakeのショートカットって、フォルダーとして見えるんですけど、実体は別の場所にあります。いわば“リンク”なんですね。
ここで重要なのが、「ショートカットそのものを削除する」のと、「ショートカットの中のファイルを削除する」のとで、結果がまったく違う、という点です。
まず、ショートカット自体を削除した場合。これはリンクを消すだけなので、参照先のデータは消えません。
ところが、ショートカットで見えているフォルダーの中に入り込んで、その中のファイルを削除してしまうと……それは“本物”のファイルを消すことになります。
つまり、「ショートカット経由で中身を消すと、参照先の実データも消える」という仕様なんですね。これはうっかりやると怖いところです。
もうひとつ大事なのが、TablesとFilesの置き場所のルールです。
OneLakeの「Tables」に置いたショートカットのうち、テーブルとして扱われるのは、Delta形式のショートカットだけです。
このDeltaテーブルであれば、SQLの分析エンドポイントからテーブルとして参照できます。
一方で、CSVが入ったフォルダーみたいな、「テーブルと判断できないもの」をTablesに置いてしまうと、「正体不明」という扱いになってしまって、テーブルとしては使えません。
なので運用としては、ファイル系のデータは「Files」に、Deltaテーブルは「Tables」に、というふうに置き分ける必要があります。ここを混ぜてしまうと、「SQLから見えないテーブル」が増えてしまうわけですね。
さらにややこしいのが、削除ダイアログの文言です。
ぱっと見では、「ショートカットを消すのか」「中身を消すのか」が分かりづらくて、うっかり本物のデータを削除してしまうリスクがあります。
筆者は、まずテスト用フォルダーで動作をしっかり確かめておくこと、そして「中のファイルを消すと参照先も消える」という公式ルールを前提に、かなり慎重な運用をするべきだと提案しています。
データ基盤を運用しているチームにとっては、「ああ、そういう仕様だったのか」と冷や汗もののポイントが整理されている記事でした。
。。。。
四本目は、ちょっと趣向が変わってオピニオン寄りの記事です。
テーマは、「速くて、確率だけ返してくれるタイプの、Jev互換のSystemー1型AIを、リアルタイムのゲーム操作に使えるのか？」という検証。
対象ゲームは、『人生オワタの大冒険ツー』。あの、理不尽な穴ジャンプとかで有名なやつですね。
筆者はまず、このSystemー1型モデルを、実時間でのゲームプレイに使ってみます。Mac上やGoogle Cloud上で計測すると、モデル自体の推論速度はかなり高速。
ところが、一見地味な「画面を読む処理」だけで、すでに約五十五ミリ秒かかってしまう。
モデルの応答時間も積み上がると、全体として、足場やトゲが動くスピードに追いつけなくなります。結果として、穴ジャンプを六百回試しても、一度も成功しなかったそうです。
そこで筆者は発想を変えて、マリオの有名なAIデモにならって、「物理とタイミングで決まる部分」はすべてコードでやってしまうことにします。
つまり、キャラクターの着地位置の計算とか、「この位置は安全か危険か」、SAFEかDEATHかの判定、さらに将来のシミュレーションといったところまでは、ぜんぶロジックで計算してしまう。
で、AIには、「その結果の中からどれを選ぶか」だけを任せる形にしたんですね。
すると、AIはSAFEかDEATHかといった判定自体はきちんと読める。
ただ、「SAFEの中から右側を優先して選ぶ」という、一行の手書きルールと比べて、成績の優位性がまったくなかったそうです。
むしろ、モデルの応答遅延、およそ百四十四ミリ秒が余計に乗ることで、パフォーマンスは大きく悪化してしまいました。
この実験から筆者が言っているのは、Systemー1モデルを画面操作や自動テストに使うときでも、まずはタスクを三つに分けよう、という話です。
一つ目は、「コードで決められる部分」。物理法則や単純な条件分岐などです。
二つ目は、「高速だけど、あいまいな判断が必要な部分」。
三つ目は、「遅くてもよいから、人やLLMに任せてもいい部分」。
この三つを切り分けた上で、「コードで書けるところには、わざわざ判定モデルを挟まないこと」が大事だと。
さらにPoCをやるときには、「モデル抜きの対照実験」をちゃんと用意して、遅延の影響や、入力トークン数、プロンプト文言の偏りなんかもセットで検証しよう、と強く主張しています。
AIが使える場面と、使わないほうがいい場面を、冷静に線引きしていこう、というメッセージのこもった一本でした。
。。。。
最後、五本目は、Claude CodeのMods機能を使った、実用的なTips系の記事です。
テーマは、「セッションごとにTODOとメモをMarkdownで管理できる『sessionーmemo』modを作ってみた」という内容。
このmodを入れると、Claude Codeの入力欄の上の帯のところに、メモの件数表示と、「メモを開く」「マークダウンファイルで開く」というボタンが出てきます。
さらに、「スラッシュ・メモ」というコマンドでも操作できるので、キーボードだけでサクサク呼び出せるようになっています。
メモの実体は、作業ディレクトリ直下の「ドット・セッションーmemo」フォルダーの下に、Markdownファイルとして保存されます。
独自形式にはせず、あえて普通のMarkdownにしておくことで、エディタのファイルペインから直接編集できますし、Git管理からも簡単に除外できます。
「ツールの都合に合わせるんじゃなくて、普段の開発フローに自然になじむ形にしている」のがいいですよね。
UIまわりの工夫も詳しく書かれていて、BoxとかText、Button、Inputといった、限られた部品だけで構成していること。
さらに、Claude Codeのペイン内に表示されたテキストは、選択コピーができない仕様なので、「コピー」ボタンと「すべてコピー」ボタンを用意して、そこから内容をクリップボードに持っていけるようにしている、という細かい気遣いも紹介されています。
ModsそのものはTypeScriptで、画面や動作を拡張できますが、右上のアイコン列に独自ボタンは足せないとか、テキストエリアコンポーネントがないとか、いくつか制約もあるそうです。
それでも、「小さな補助ツール」レベルであれば、Claudeに『こういうmodを作って』とプロンプトするだけで、大枠を自動生成してくれるので、そこから自分好みにカスタマイズしていくのはかなり現実的だと。
自分の作業環境をちょっとずつ便利にしていく、その具体的なイメージがわく記事でした。
。。。。
というわけで、今日は全部で五本ご紹介しました。
一〇年前のJava環境をDockerで再現して、エラーと格闘しながら「学び方」を問い直す記事。
ECツーのキャパシティ不足を、朝だけオンデマンド予約する仕組みで乗り切るStep Functionsの構成。
OneLakeのショートカット運用で気をつけたい、「中身を消すと本物も消える」仕様と、TablesとFilesの置き分け。
リアルタイムゲームでのSystemー1型AIの限界を通じて、「コードで書けるところにAIを挟まない」大事さを説いたオピニオン。
そして最後は、Claude CodeのModsで、セッション単位のMarkdownメモを管理する「sessionーmemo」modの作り方と工夫、というラインナップでした。
気になった記事があれば、詳しい内容や元の記事へのリンクは、番組のショーノートにまとめておきますので、ぜひそちらもチェックしてみてください。
「zenncast」では、番組の感想や、「こんなテーマを取り上げてほしい」といったリクエストもお待ちしています。
ラジオネームを添えて送ってもらえると、番組内でご紹介させていただくかもしれません。
それでは、そろそろお別れの時間です。
今日も一日、ゆるっとがんばっていきましょう。お相手はマイクでした。
また次回の「zenncast」でお会いしましょう。いってらっしゃい。