おはようございます！ zenncast、マイクです。
今日は10月19日、月曜日。朝7時になりました。新しい1週間のスタートですね。今朝もZennで今日トレンドの記事から、開発のヒントになる話題をお届けします。
今日は、テストの考え方から、スマホで進める開発、技術書サービスの活用、AIエージェントの実行基盤、そしてデータ復旧の教訓まで、5本の記事をご紹介します！
....
まず1本目は、「良いテストって、どんなテスト？」というお話です。
良いテストは、壊れたら知らせてくれて、壊れていなければ失敗しないもの。不具合を見つける力はもちろん大切ですが、それだけではありません。コードを整理しただけで失敗しないか、実行は速いか、保守しやすいか。こうした観点も含めて評価しよう、という内容です。
テストで確かめたいのは、内部でどの順番に処理を呼び出したか、非公開の変数がどうなっているか、ではなく、入力に対してどんな結果が返るか、画面に何が表示されるか、といった外から見える振る舞いです。期待する結果も、今の実装をそのまま写すのではなく、仕様から決めることが重要なんですね。
AIにテストを作ってもらう場合も、実装だけでなく仕様を渡します。そして、生成されたテストが本当に結果を検証しているのかは、人が確認する必要があります。テストの網羅率は、まだ確認できていない場所を探すための補助。数字そのものを目標にはしない、という考え方です。
設計では、業務上の判断と、データベースの読み書きを分けます。判断の部分は、速い単体テストで細かく確認する。一方、データベースとのつながりは、統合テストで重要な流れを確認する。この役割分担がポイントです。
すでにある設計を直すなら、まず統合テストで現在の動作を守ります。そのうえで判断部分を切り出し、細かな確認を単体テストへ移していく。安心できる土台を作ってから、少しずつ整えるわけですね。テストが変更の足かせではなく、変更を支える味方になっているか。見直すきっかけになりそうです。
....
続いて2本目は、スマホから自宅のMacに開発をお願いするお話です。
Claude CodeのRemote Controlを有効にすると、スマホのClaudeアプリから、自宅のMacに開発を指示できます。ポイントは、実装を頼むだけでなく、スマホだけで実機確認まで進められることなんです。
そのためには、外出前の準備が大切です。TestFlightなどへ、コマンドでアプリを配信できるようにしておきます。そうすれば、実装が終わったあとに「配信して」と指示して、配信されたアプリをスマホにインストールし、そのまま動作を確認できる、という流れです。
さらに、配信手順をClaude Codeのスキルとして登録しておけば、毎回同じ説明をする負担を減らせます。完了通知も設定しておくと、作業が終わるまで何度も様子を見に行かずに済むんですね。
Macと同じWi-Fiにつながっている場合は、iOS端末にワイヤレスで直接インストールする方法もあります。こちらは、TestFlightの処理待ちを省けるのがうれしいところです。
ただし、ビルドやテストが動くのは、すべてMac側です。Macの電源を入れ、Claude Codeも稼働した状態にしておく必要があります。また、ログインやCAPTCHAなど、人の操作が必要な場面では、PCに戻ることになります。
スマホが開発マシンそのものになるというより、手元から開発と配信を進める窓口になるイメージですね。準備を整えておけば、場所に縛られない開発の選択肢になりそうです。
....
3本目は、O'Reillyを割安に利用する方法と、その使いどころについてです。
記事で紹介されているのは、国際学会のACMに入会し、Skills Bundleを追加する方法です。O'Reillyの直接契約は年499ドルですが、ACM経由なら初年度は150ドル、翌年以降は174ドル。ただし、初年度の割引を受けるには、専用ページから申し込む必要があります。
利用できる内容にも違いがあります。書籍や動画、オフライン閲覧は使えますが、ライブイベントや資格対策は対象外です。また、日本語の本を探したい場合は、言語設定に日本語を追加しておく、というポイントも紹介されています。
そして、ACM経由の利用でも、Claudeから蔵書を検索するMCP連携が使えます。ブラウザで認証する際には、ACMのユーザー名に「@acm.org」を付けたものを入力する、という手順です。
気になるのは、どれくらい使えばお得なのか、ですよね。記事では、1冊4,000円と考えると、ACM経由でも年に7冊ほど読まないと、本を購入するより安くはならないとしています。
ただ、筆者が価値を感じているのは、読んだ冊数そのものよりも、「買うほどではない本を、気軽につまみ読みできる」こと。気になる技術について少し調べたり、複数の本を見比べたり。そうした使い方まで含めて、自分に合うか考えるとよさそうですね。
....
続いて4本目は、LLMエージェントを動かす実行基盤、「Harness」の設計についてです。
Harnessは、モデルを呼び出し、その結果を受けてツールを実行する、という流れを繰り返す仕組みです。長時間にわたる処理や、予期しない操作が起きることを前提に、どう設計するかがテーマになっています。
まず大切なのが、処理の実行と、画面への進捗表示を分けることです。これによって、ブラウザを閉じても処理を続けられます。履歴を保存しておき、再接続したときに途中経過を送り直せるようにする、という構成です。
また、ステップ数や費用、制限時間は、モデルにお願いするだけではなく、コードで制限します。同じ操作を何度も繰り返していないかも検出し、必要なら止める。動作の境界を、仕組みとして用意しておくわけですね。
モデルの出力は、ツールを実行する前に保存します。そして、ツールでエラーが起きたら、その内容をモデルへ返します。そうすることで、引数を修正したり、別の方法を試したりする再試行につなげます。
モデルAPIへの接続処理を共通化することもポイントです。利用上限への対応、障害時の再試行、別のモデルへの切り替えを、まとめて管理できるようにします。
そして、手順が決まっている仕事なら、まずは固定の処理順序から始める。モデルに自由な判断を任せたり、複数のエージェントに分担させたりするのは、必要になった場合だけ加える、という方針です。
賢いモデルを使うことと、安定して仕事を進められることは、別に考える必要があるんですね。エージェントの周りにある、記録や制限、復旧の仕組みの大切さが伝わってきます。
....
最後、5本目は、不要なデータが約2,000万件に膨らんだ事例と、そこから得られた教訓です。
きっかけは、出荷明細を再作成する際のミスでした。本来の対象だけでなく、別の明細の補足情報までコピーしてしまい、処理を繰り返すたびに不要なデータが増えていったそうです。その結果、約2,000万件という規模になりました。
復旧では、荷主側のデータと比較して、どの情報を残すべきかを判断しました。さらに、調査と削除を小分けにして進め、その進捗を保存することで、業務に新たな影響を出さないように対応したということです。
ここから筆者が伝えているのは、「処理が正常に終わった」だけでなく、「処理後のデータが正しいか」をテストする重要性です。
必要な情報がきちんと残っているか。無関係な情報が混ざっていないか。そして、同じ処理を再実行しても、正しい状態を保てるか。そこまで確かめる必要があります。
エラーが出なかったから大丈夫、とは限らないんですね。最初にご紹介したテストの記事にもつながる、結果の正しさを確かめることの重みを感じる事例でした。
....
さて、今朝のzenncastは、5本の記事をお届けしました。
変更を支える良いテストの考え方、Claude Codeでスマホから実装と実機確認を進める方法、ACM経由でのO'Reilly活用、LLMエージェントを支えるHarnessの設計、そして、約2,000万件の不要データから学ぶ、処理後の状態を確認する大切さでした。
詳しい内容はショーノートに書いてありますので、気になった話題をぜひチェックしてみてくださいね。番組の感想もお待ちしています。「この話が役に立った」「こんなテーマも聞いてみたい」など、気軽にお寄せください。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入ったら、登録や高評価をつけてもらえるとうれしいです！
それでは、次回またお会いできるのを楽しみにしています。お相手はマイクでした。今日も、良い1日を！