どうも、マイクです。おはようございます。
九月三十日、水曜日の朝七時になりました。今日も「zenncast」、元気にお届けしていきます。
この時間は、技術系ナレッジ共有サービス「Zenn」から、いまホットなトレンド記事をピックアップしてご紹介していきます。コーヒー片手に、通勤通学の準備をしながら、耳だけ貸してもらえたらうれしいです。
さて今日は、お便り紹介はお休みで、そのぶんたっぷり記事を取り上げていきます。
今日ご紹介する記事は、ぜんぶで五本。AI時代のテストの話から、Git には戻れないと感じた新しいバージョン管理ツールの話、トランザクション設計、AWS をパートナー企業と安全に共有する話、そして Rust 製の自作 OS が大学の授業で使われているという、めちゃくちゃ熱い話まで、幅広く揃ってます。
ではさっそく、一つ目からご紹介していきましょう。
まず一つ目は、「AI がコードを書くようになっても、テストの役割はどう変わるのか？」というテーマの記事です。
ポイントは、テストの役割そのものは実はそんなに変わらないよ、という主張なんですね。
大事なのは、テスト一つ一つが「どんな種類の不具合を」「どれくらいの速さで」見つけられるのか、この二つの軸でちゃんと役割分担してあげることだ、という整理がされています。
たとえば、ロジックの間違いとか、境界値のチェックみたいな部分は、できるだけ速いレイヤーで機械的にカバーする。具体的には、型システムとか、lint、ユニットテスト、それからプロパティベーステストみたいな、サクサク回るテストたちの出番です。
一方で、データベースをまたいだ処理とか、画面遷移を含むような動作、ブラウザごとに挙動が変わりそうなところなんかは、インテグレーションテストや E2E テストに任せていきましょう、という分け方が提案されています。
そのうえで、「人間がどこにいちばん投資すべきか」という話が面白くて、記事では、型やユーザー定義型の設計、それからコンストラクタでのチェックにコストをかけるべきだと強調しています。
つまり、そもそも「おかしな値」や「ありえない状態」をプログラムの世界の中で表現できなくしてしまう。そうすると、AI が自動生成したテストを、一本一本細かくレビューしなくても、ある程度安心して任せやすくなるよね、という考え方です。
さらに、探索的テストの位置づけも整理されています。
探索的テストって、「仕様書には書いていないけれど、実はユーザーが踏みそうなバグ」を探すための活動ですよね。記事では、そうやって見つかったバグを、ただ修正して終わりにするんじゃなくて、「同じタイプの問題が二度と起きないように」より速いレイヤーに落とし込んでいくべきだ、と書かれています。
たとえば、よくある入力ミスを見つけたら、それを型やユーザー定義型で表現できないようにするとか、lint のルールにするとか、自動テストに追加するとか。
こうやって、探索的テストで拾った“仕様の外”のバグを、どんどん型や自動テストの世界に取り込んでいくことで、AI が書くコードやテストも、だんだん安全なレールの上に乗せられるよね、という提案になっています。
AI がコーディングをどんどん肩代わりしていく中で、人間は「どこに境界線を引くか」とか「どんな型で世界を切り取るか」といった設計の部分をやる、というのが、この記事のメッセージかなと思いました。テストを書いている方はもちろん、最近 AI コーディングにモヤモヤしている方にも刺さる内容じゃないかなと思います。
。。。。
続いて二つ目は、「Jujutsu（ジュジュツ）」という、Git 互換の新しいバージョン管理ツールに乗り換えたら、もう Git には戻れなくなった、という体験談の記事です。
AI にコードを書かせる機会が増えると、細かい差分がガッと出たり、コミットの粒度が曖昧になったりして、Git の運用が妙にストレスフルになることってありますよね。この記事の筆者も、まさに Git の煩雑さとか、誤操作の不安を強く感じていたそうです。
そこで出てくるのが Jujutsu です。特徴のひとつが、「インデックスがない」という点。
Git だと、ワークツリーで作業して、それをインデックスに add して、そこから commit しますよね。この途中の状態管理が、けっこうややこしい。
Jujutsu ではこのインデックスがなくて、作業ディレクトリの状態が、ほぼ常に履歴として残るようなモデルになっているので、「あ、add し忘れた」「commit する前に作業消しちゃったかも」という不安から、かなり解放されると書かれています。
さらに、履歴がこまめに残っているので、undo もしやすくて、「やばい、さっきの変更戻したい」がだいぶ気楽になるというわけですね。
もう一つのキーワードが、「change」という単位です。
Git のブランチよりも軽量な概念で、実験的な変更をサクッと作って、気に入らなければすぐ捨てて、後からまた復元する、というサイクルがとてもやりやすい。
その結果として、「ちょっと試してみるか」というトライ＆エラーの心理的ハードルがぐっと下がった、と筆者は語っています。AI が生成したコードを、いくつかバリエーション試したいときなんかにも良さそうですよね。
履歴の書き換えも面白くて、Jujutsu では「過去のある地点に移動して編集すると、その変更が自動的に後続に rebase されていく」という設計になっています。
Git の rebase コマンドって、オプションも多いし、ちょっと怖いイメージがありますが、Jujutsu ではそれがもっと直感的に扱える。履歴の修正が、「過去にタイムスリップして書き直す」くらいの感覚でできるようになっているんですね。
さらにログ表示も特徴的で、履歴全体を二次元のグラフとして見渡せる UI を備えています。分岐してまたマージして…という歴史が視覚的にわかりやすくて、「あ、この辺で別の実験してたんだな」とか、「ここからここまでが一連の作業だな」といったイメージが掴みやすい。
そして一番大きな安心材料が、裏側では普通に Git リポジトリを使っているという互換性の高さです。
チームとしてはこれまで通り GitHub を使い続けられて、CI も変えなくていい。そのうえで、自分のローカルだけ Jujutsu をクライアントとして使って、より快適に開発できる。
「今ある仕組みはあまり壊したくないけど、Git のツラさは和らげたい」という人にとっては、かなり現実的な選択肢になりそうだなと感じました。
。。。。
三つ目は、トランザクション設計の基本を、すごく整理して説明してくれている記事です。
トランザクションの中の処理って、全部同じように見えがちなんですが、この記事では「失敗したときにどう扱うか」という観点から、三種類に分けよう、と提案しています。
一つ目が「非保護」の処理。これは、失敗してもまあ放置でよいもの。ログを書こうとして失敗した、とか、その程度でシステムの整合性に影響しないものですね。
二つ目が「保護」の処理。トランザクションロールバックで一緒に巻き戻せるものです。たとえば在庫の更新や、注文テーブルへのレコード挿入なんかが典型ですね。
三つ目が「実」の処理。これは一度やったら取り消せないものです。ユーザーへのメール送信とか、外部決済サービスへの実行リクエストとか、そういった外の世界に影響を及ぼすアクションがここに入ります。
問題になるのは、この「実」の処理を、保護されたトランザクションの前にやってしまうケースです。
記事では、注文確定メールを先に送って、そのあとで在庫更新などの「保護」処理を実行する、という例が挙げられています。
もしこの後半の処理が失敗してロールバックされた場合、ユーザーの側には「ご注文が確定しました」というメールが届いているのに、システム上は注文が確定していない、というねじれが起きてしまいます。これは、問い合わせ対応やクレームの温床になりますよね。
そこで提案されているシンプルなルールが、「取り消せない実アクションは、できるだけ最後に実行する」という順番の約束ごとです。
まずはトランザクションに含めるべき「保護」の処理をきっちりまとめて実行して、全部が問題なく成功したことを確認する。そのあとで、メール送信などの「実」のアクションを実行する。
これだけでも、多くのケースで不整合のリスクをかなり減らせる、と記事では説明しています。
とはいえ、現実のシステムでは、「実」のアクションが複数あったり、その結果を使ってさらに別の処理をしたかったりと、もう少し複雑な状況も出てきます。
そういう場合には、いわゆるトランザクショナルアウトボックスパターンのような、別の設計パターンも検討する必要がありますよ、という形で記事は締めくくられています。
トランザクション設計でモヤモヤしている方とか、メール送信や外部 API 連携をどこに入れるか悩んでいる方には、すごく腹落ちしやすい整理になっているなと感じました。
。。。。
四つ目は、AWS の環境を、別の会社の開発チームにも安全に触ってもらうにはどうしたらいいか、という「現場感」あふれる設計の話です。
この記事の会社では、もともと Google Workspace と IAM Identity Center を組み合わせた ID 基盤があって、そこに社員のアカウントが乗っている状態でした。AWS TEAM もその仕組み前提で動いているので、社外のパートナー企業のエンジニアを、同じ基盤の中に入れてしまう、という使い方には向いていなかったんですね。
そこでとったアプローチが、パートナー企業ごとに AWS アカウントを用意してもらって、そこからクロスアカウントで自社の IAM ロールを引き受けてもらう、という構成です。
この仕組みで、「誰を信頼するか」と「どこまで任せるか」をきれいに分けて設計できるようにしています。
自社側では、「どの会社を信頼するのか」「その会社に何をさせてよいのか」という部分を、Infrastructure as Code、つまり PR ベースの IaC で管理します。
一方でパートナー企業側には、「どの個人がそのロールを使えるのか」というユーザー管理と、その人を識別する sourceIdentity、つまり“この操作をしたのは誰か”のラベルの正しさを担保してもらう、という役割分担です。
ロールの設計も四層構造になっていて、
まず一つ目が「誰がそのロールに入れるか」という入口の制御。
二つ目が「絶対にさせないこと」、たとえば本番環境の削除系操作など、禁止事項を明示するポリシー。
三つ目が「許可する能力」、DB の参照とか、踏み台サーバー経由の接続など、業務に必要な最低限の権限。
そして四つ目が、「各社ごとの制御」、パートナー企業側でさらに細かく制限をかけられるような層。
こういう四枚重ねで、必要最小限の操作だけを許すようにしているのがポイントです。
sourceIdentity については、AWS 側から見るとある意味「自己申告」に近いところがあって、そこに穴がありえます。
この記事では、その弱点を、「パートナー側の IAM 設定と、契約の取り決め」でしっかり縛ることでカバーしています。
さらに、CloudTrail を活用して、だれが、いつ、どのロールを使って、どんな操作をしたのかを、個人単位まで追えるようにしている。これによって、「会社としてどこまで信頼し、問題があったときにはどこまでトレースできるか」というラインが、かなりクリアになります。
社外の開発チームと一緒に本番環境を触る、というのは、どの会社でも緊張するポイントですが、「信頼の単位」と「責任の分かれ方」をきちんと設計してあげることで、意外とシンプルに運用できるんだな、と思わせてくれる記事でした。
。。。。
そして五つ目、最後はちょっとロマンがある話です。
Rust で書かれた自作の Unix 風 OS、「octox」というプロジェクトがあるんですが、この OS がサンフランシスコ大学の OS 授業で、実際の教材として使われている、という事例を紹介した記事です。
授業では、OS の基本的な概念――たとえばブートの仕組み、仮想メモリ、プロセス管理、システムコール、ファイルシステムといったトピックを説明しながら、その裏で octox の Rust による実装を一緒に読み進めていくスタイルになっています。
教科書だけではイメージしづらい部分を、実際のコードで確かめられるのがいいですよね。
課題もかなり実践的で、まずは Unix コマンドの `seq` や `tail` のようなものを追加実装してみるところから始まります。
次に、`pipecount` というコマンドを通して、プロセス間通信とパイプの動きを理解していく。
さらに発展として、カーネル側に計測機能を追加して、各プロセスが何回システムコールを呼び出したかとか、どれくらいメモリを使っているかを観測できるようにする、といった課題が出されるそうです。
これによって、「OS の上で動くプログラムを書く」段階から始まって、最終的には「OS 自体を拡張して、その挙動を追いかける」ところまで、一通り体験できるカリキュラムになっています。
記事の筆者は、AI がコードを書いてくれる時代だからこそ、プロセスとかパイプといった OS の仕組みを人間がきちんと理解しておくことが、AI を動かす環境を設計したり改善したりするうえで、ますます重要になっていると述べています。
AI のモデル本体だけじゃなくて、それを支える OS、コンテナ、スケジューラ、そういったレイヤーがわかっているかどうかで、設計の質が大きく変わるよね、という視点ですね。
そのうえで Rust の強みである「型による誤り防止」と、Verus や Lean のような形式検証ツールを組み合わせると、面白い世界が見えてくるとも書かれています。
人間が書いたコードであっても、AI が生成したコードであっても、こういったツールを使えば、安全性や正しさを効率よく高めていける。
「AI が書くから仕組みはよくわからなくていい」ではなくて、「AI が書くからこそ、仕組みを形式的に検証して支えてあげる」という発想が、これからのシステム開発では鍵になりそうだなと感じました。
というわけで、きょうご紹介した記事は、ぜんぶで五本でした。
AI 時代のテスト設計の話から始まって、Git から Jujutsu に乗り換えた開発体験、トランザクションの「非保護・保護・実」という整理、AWS をパートナー企業と安全にシェアするためのロール設計、そして Rust 製 OS「octox」が大学の授業で使われているという教育と安全性の話まで、かなり盛りだくさんでしたね。
気になる記事があれば、この番組のショーノートに詳しい情報を載せておきますので、ぜひあとでゆっくりチェックしてみてください。
番組への感想や、「こういうテーマも取り上げてほしい」といったリクエストも、いつでも募集中です。あなたの現場での悩みや気づきが、ほかのリスナーの学びになるかもしれません。
それでは、そろそろお別れの時間です。
今日も「zenncast」、お相手はマイクでした。
また次回お会いできるのを楽しみにしています。それでは、いってらっしゃい。