AI と Unity と C# / .NET

２０２５年に私が書いた投稿をまとめた、年末年始にぴったりなスーーゴイ長い投稿です。

※ AI 関連の投稿の中に、ちょっと便利なツールに関するモノも紛れています。探してみてね！

👇 スゴイ長いのでポッドキャストでも聞きながらどうぞ

プロンプトと各 AI の出力内容の雑感

以下のプロンプトに従って６つの AI を使って生成しています。Notebook LM については一切指示せず出てきたものをそのまま使っています。

articles/ には「今年書いた記事」が .md ファイルとして保存されています。
それぞれのファイルについて、以下の形式で Lookback2025.md に纏めてください。
一覧性を高めるため、記事のタイトルの前に**必ず**空白行を５行入れてください。

**IMPORTANT**: 記事のタイトルから明らかな事柄を、まとめや概要に含めてはならない

--

# 記事のタイトル

- ${三行まとめをバレットリストで}

https://zenn.dev/sator_imaging/articles/${fileNameWithoutExtension}

${概要（400文字程度）}

各 AI の生成結果の雑感

• OpenAI Codex
  • 最もお気に入りで常用しているツール
  • 指示に対して最も忠実で、投稿タイトルに出ている固有名詞を（極端すぎる程に）概要に含めない
• Gemini 3 Pro
  • 文字数に関しては最も忠実に見える。原稿用紙１枚分を守ろうとしている
• Claude Sonnet が GPT OSS 128B と同レベル
  • そもそも指示を守っていない。タイトルに含まれる情報を愚直に繰り返すことで文字数を浪費している
  • それ以前にすべての概要と記事が一つずつズレていた（なので概要が一つ欠落している）
    • プロンプトの文章構成（リストの後に URL）も悪いが、そもそもそういう問題ではない
  • 加えて「英語で４００文字の概要」を考え、それを日本語に直訳しているので非常に淡白な内容
  • 使い物になるのか？ という感じ（TDoubles で酷い結果を目の当たりにして以降、一切信用していない）
  • ultrathink を指示していないが、そういうレベルじゃない酷さ
  • （邪推）Antigravity で Claude が無料で使えるのは、Google が「ユーザーが Claude に指示した内容」「それに対する Claude の返答」を学習する為だと思うので、凝ったシステムプロンプト等を意図的に排除している気がする。流石に結果が酷すぎる
  • もしくは単純にコーディング以外が全然ダメなだけ？

意外だったのは、GPT OSS 128B の出力結果の精度の高さ。ただ、指示しなかったとは言え最初は英語で出力されてしまいました。せっかくなのでそれらも日本語版と併記しています。

非同期処理ブートキャンプ【2025年版】

Notebook LM

C#における非同期処理の本質をUnity開発の視点から紐解いた技術解説記事です。著者は、async/awaitが単なる糖衣構文であり、その実体はUnityのコルーチンやIEnumeratorと同様に**状態を保存して再開できる関数オブジェクト（ステートマシン）**であることを強調しています。

主な内容は、非同期処理がGUIをフリーズさせない仕組みの解説から、メインスレッドを停止させることで発生するデッドロックの原因と対策、さらにはUnity 6の新機能まで多岐にわたります。特に、非同期処理は並列処理（マルチスレッド）とは別物であり、**「同期処理を細切れにして実行機会を増やす」**ことで並行性を実現しているという技術的な視点を提示しています。

最終的に、非同期処理を万能な魔法としてではなく、オーバーヘッドやキャンセルの難しさといった制約を伴う道具として正しく理解し、必要最小限の範囲で適切に利用することを推奨する構成となっています。

GPT 5.2-Codex

• 状態機械としての理解で async/await を再構成
• Unity コルーチンとの等価性を示す構造的説明
• デッドロックや ValueTask など落とし穴の整理

「非同期」は糖衣構文であり、実体は状態を保持する関数オブジェクトだという視点で解説する。IEnumerator とコルーチンのコンパイル結果を示し、async/await が同様のステートマシンに変換されることを確認。並行/並列、起動済みタスク、デッドロック、ValueTask、キャンセルの難しさ、ConfigureAwait など実務で詰まりやすい要素を体系的に整理している。

Gemini 3 (Pro w/Antigravity)

• async/await と Unity コルーチン（IEnumerator）のステートマシン構造と比較解説
• GUI アプリのメインループと同期コンテキストにおけるデッドロック発生メカニズムと回避策
• Unity 6 の Awaitable.MainThreadAsync や「起動済みタスク」に関する問題の深掘り

C# と Unity における非同期処理（async/await）の仕組みを、コンパイル後のステートマシン構造や Unity コルーチンとの比較を通じて深く掘り下げた解説記事です。非同期メソッドがどのように分割され、メインスレッドのループ（同期コンテキスト）上で実行されるのかを図解的に説明しています。特に GUI アプリで頻発するデッドロックの原因を構造レベルで解き明かし、ConfigureAwait(false) や Task.Run による一般的な対策に加え、Unity 特有の UnitySynchronizationContext.Exec() を用いた力技の回避策まで、実践的かつ深入りした内容が網羅されています。

Gemini 3 (Auto w/CLI)

• 非同期処理の実体であるステートマシンの構造と、Unityコルーチンとの共通点の解説。
• GUIフリーズ回避の仕組みや、デッドロック発生のメカニズムとその回避策。
• ValueTaskの適切な使用場面や、Unity 6以降の非同期処理の在り方についての考察。

C#およびUnityにおける非同期処理（async/await）の内部動作を、IEnumeratorやUnityコルーチンと比較しながら深く掘り下げる解説記事です。コンパイル後のステートマシン構造、同期コンテキストとデッドロックの関係、Task.RunやConfigureAwaitの挙動などを詳述し、非同期処理を適切に扱うための知識をまとめています。

Gemini 2.5 (Auto w/CLI)

• async/awaitが実際にはコンパイラによってステートマシンに変換される糖衣構文であることを、IEnumeratorとの比較を通じて解説します。
• GUIアプリケーションでデッドロックが起きる仕組みと、Task.RunやConfigureAwait(false)を使った基本的な回避策を説明します。
• 非同期処理は高速化のための技術ではなく、「GUIをフリーズさせない」ための並行処理技術であると明確にし、並列処理との違いを整理します。

C#の非同期処理の仕組みを、その根源であるステートマシンの概念から丁寧に解き明かす包括的な解説記事です。async/awaitが単なるキーワードではなく、コンパイラが裏側でどのようなコードを生成しているのかを明らかにします。Unityのコルーチンとの類似性を示しながら、デッドロックの発生メカニズムやその回避方法、ValueTaskの適切な使いどころ、そして多くの開発者が誤解しがちな「非同期処理で速くなるわけではない」という真実まで、非同期プログラミングをマスターするための必須知識を網羅します。

Claude Sonnet 4.5 (Antigravity)

• 非同期処理の仕組みを徹底解説
• IEnumerator、Unity コルーチン、async/await の関係性とステートマシンへの変換を説明
• デッドロックの原因と対策、ValueTask、キャンセル処理など詳細に解説

非同期処理の仕組みを徹底解説。IEnumerator、Unity コルーチン、async/await の関係性、ステートマシンへの変換、デッドロックの原因と対策、ValueTask、キャンセル処理など、非同期処理の本質を詳細に説明しています。

GPT OSS 128B (Antigravity)

• 最新の async/await と Promise の概念を体系的に解説
• キャンセル、並列制御、実践的演習を提供
• サンプルプロジェクトでのハンズオンを実施

本ブートキャンプは、2025 年版として最新の非同期プログラミング手法を体系的に学ぶ教材です。概念解説に加えて、キャンセルや同時実行数制御の実装例、ハンズオン用サンプルプロジェクトを通じて実践的に習得できます。

• Offers a comprehensive overview of modern async techniques.
• Covers promises, async/await, cancellation, and concurrency limits.
• Includes hands‑on exercises and sample projects.

The bootcamp article serves as a curriculum for mastering asynchronous programming in 2025. It blends theory with practical labs, guiding readers through building robust, scalable async workflows.

【TypeScript/C#】 軽量スレッドライブラリ

Notebook LM

TypeScriptとC#の両環境で利用できる軽量スレッド（ファイバー）ライブラリの機能と設計思想を解説しています。

本ライブラリは、標準的な非同期処理のラッパーとして動作し、同時実行数の動的制御やタスクの中断・再開を容易にすることで、大量のデータ処理における負荷調整を効率化します。内部的には言語標準のイテレーターを活用しており、メモリ効率の最適化を図りつつ、複雑な非同期ジョブのスケジューリングを簡潔な記述で実現しています。

また、AIを活用したユニットテストの導入やUnity環境での特殊な運用手法など、開発プロセスの自動化と柔軟性を重視した技術的な試みについても触れられています。

GPT 5.2-Codex

• 競合しやすい大量ジョブを安全に回すための並列数制御と中断/再開の設計
• 完了順の列挙と元データ保持の両立を意識した API とサンプル
• スケジューラーやバックグラウンド実行など運用面の小技を整理

Promise.race/Task.WhenAny 的な構成を核に、完了順列挙・動的な同時実行数変更・停止などを行える設計を紹介している。配列とインデックスの双方を扱えるファクトリー、結果に元情報を付与する戻り値の工夫、FiberScheduler による優先キューの扱い、バックグラウンド実行のパターンなど実用寄りの使い方が中心。大量ダウンロードのログ例や、Unity 向けのテスト運用小話も添えられている。

Gemini 3 (Pro w/Antigravity)

• 軽量スレッド（ファイバー）を用いて大量の非同期処理を効率的に並列実行・制御するライブラリ「ts-fibers」およびそのC#移植版の紹介
• Fibers.ForEach や FiberScheduler を使用し、同時実行数の制限や動的な優先度変更が可能
• Unity環境でのテスト実行支援機能「FUnit」や、メモリ使用率などのパフォーマンス計測結果についても言及

TypeScriptおよびC#（.NET/Unity）向けに開発された、いわゆる「軽量スレッド」や「ユーザーモードスレッド」のような挙動を模倣するライブラリの解説記事です。数千・数万単位のHTTPリクエストなどの非同期タスクを、単なる Promise.all や Task.WhenAll で投げっぱなしにするのではなく、指定した同時実行数（Concurrency）で制御しながら処理する仕組みを提供します。記事では基本的な使い方に加え、実行中のメモリ消費量の推移や、優先度付きスケジューラーによる割り込み処理、さらにバックグラウンド実行や途中キャンセルといった制御フローについてもコード例を交えて説明しています。また、開発の副産物としてUnityのテストをGitHub Actions上で実行するための仕組みも実装されたことが紹介されています。

Gemini 3 (Auto w/CLI)

• 多数の非同期タスクを並列実行数やキューで制御し、負荷やAPI制限を回避するライブラリの紹介。
• Promise.race/Task.WhenAny のラッパーとして機能し、動的な同時実行数変更などが可能。
• TypeScript版とC#移植版があり、大量のデータ収集や処理におけるメモリ効率の良さも確認。

ファイバーやコルーチンと呼ばれる軽量なスレッド概念を用い、通常のasync/awaitを利用しつつ並列実行数を制御できるライブラリ「Fibers」の解説です。大量のWebページ収集などを例に、単純な並列実行で発生するリソース不足やAPI制限（429エラー）を回避する仕組みを提供します。TypeScript版とC#版の実装があり、Unityテスト環境（FUnit）との連携についても触れています。

Gemini 2.5 (Auto w/CLI)

• TypeScriptとC#の両方で利用でき、非同期処理の同時実行数を制御する機能を提供します。
• キューの中断・再開や、完了したタスクから順に結果を取得するなどの柔軟なタスク管理が可能です。
• 多数のウェブページ収集やAPIからのデータ取得といった、大量の非同期タスクを効率的に実行するシナリオで役立ちます。

多数の非同期処理を効率的に管理するためのライブラリです。特にAPIへのリクエスト制限がある場合や、大量のデータを並列処理する際の負荷を制御したい場合に有効です。Promise.raceやTask.WhenAnyを基盤としつつ、同時実行数の動的な制御、キューの中断・再開、結果の順序保持といった高度な機能を提供します。これにより、開発者は負荷を考慮しながら、CPUとメモリを効率的に使用する堅牢な非同期コードを容易に記述できます。

Claude Sonnet 4.5 (Antigravity)

• TypeScriptとC#向けの軽量スレッディング/コルーチンライブラリ「Fibers」を紹介
• Fibers.ForEachとFibers.Forによる並列非同期処理の実装方法を解説
• Unity向けのFUnitテストフレームワークについても言及

【概要は生成されず】

GPT OSS 128B (Antigravity)

• async/await を利用した軽量スレッド抽象を提供
• 同時実行数やタスクスケジューリングを動的に制御可能
• Unity でも利用できる Fiber ベースの API を実装

この記事では、軽量スレッド（ファイバーやコルーチンとも呼ばれる）を標準の非同期プリミティブで実装する方法を紹介しています。Promise.race や Task.WhenAny を組み合わせてタスクキューを管理し、並列度を動的に調整する手法や、Unity 環境での統合例を示しています。

• Provides a lightweight threading abstraction built on async/await.
• Enables dynamic control of concurrency and task scheduling.
• Offers a Unity‑compatible API for fiber‑based workflows.

This article introduces a library that implements lightweight threads, often referred to as fibers or coroutines, using standard asynchronous primitives. It demonstrates how to wrap Promise.race/Task.WhenAny to manage task queues, dynamically adjust parallelism, and integrate the solution into Unity environments without relying on platform‑specific threading models.

【LINQ】Flatten() メソッド※

Notebook LM

C#のLINQにおいてツリー構造を平坦化するFlattenメソッドの提案と実装について記した技術記事です。

筆者は従来の複雑な記述を簡略化するため、ノードから直接呼び出せる拡張メソッド形式への改善案や、既存の実装を変更できない場合に有効な静的メソッドの活用法を提示しています。最終的には、この便利な機能を**.NETの標準ライブラリへ導入すること**を目指し、GitHubでの提案を通じたコミュニティへの支持を呼びかけています。

GPT 5.2-Codex

• ツリー探索を拡張メソッドで呼べる形にする設計変更
• ノード側を触れない場合の別 API 形状の提案
• 再帰列挙のシンプルさと API 位置付けの議論

再帰列挙でツリーを辿る実装を、IEnumerable<T> 実装側に拡張として追加する形に整理した更新。ノード型が列挙可能であれば node.Flatten() で呼び出せる設計になり、既存のノード型に手を入れられない場合は静的メソッド＋セレクタ方式の API が良いのではという補案も示す。標準ライブラリへの要望として Issue を立てた経緯と、最初期の実装も合わせて紹介している。

Gemini 3 (Pro w/Antigravity)

• 木構造（ツリー）データを持つオブジェクトをフラットな IEnumerable<T> に変換する拡張メソッドの実装
• IEnumerable<T> を実装したノードクラスに対し、再帰的に子要素を辿るロジックを紹介
• .NET Runtimeへの提案（Issue）や、SelectMany を用いた初版の実装アプローチについても触れている

階層構造を持つデータをLINQで扱いやすくするための Flatten() メソッドの実装例を紹介しています。再帰的なインターフェース IEnumerable<T> を実装したノードクラスに対し、深さ優先探索（DepthFirst）などで子要素を順次列挙し、一階層のシーケンスとして扱う方法を解説しています。当初は SelectMany を用いた複雑な実装を行っていましたが、よりシンプルで直感的な実装が可能であることに気づき、コードを改善した経緯が記されています。また、この機能を標準ライブラリに取り入れてほしいという動機から、.NET Runtime のリポジトリにIssueを作成したことや、静的メソッドとして定義する場合のAPI案など、実装の背景や標準化への期待も語られています。

Gemini 3 (Auto w/CLI)

• 階層構造を持つデータをフラットに展開する拡張メソッドの実装案。
• 深さ優先と幅優先の探索戦略を選択可能にし、再帰的な構造を扱いやすくする。
• 標準ライブラリへの採用を願い、dotnet/runtimeにIssueを起票した経緯も紹介。

木構造のようなネストされたデータ構造を、LINQで扱いやすいフラットなシーケンスに変換するFlattenメソッドの提案です。SelectManyなどで複雑になりがちな処理を簡潔にし、ノード自体に再帰的なインターフェイスを持たせる設計や、探索順序（深さ優先・幅優先）の切り替えについてコード例を交えて解説しています。

Gemini 2.5 (Auto w/CLI)

• 再帰的なデータ構造をフラットなシーケンスに変換するLINQ拡張メソッドの実装案を提案しています。
• 当初の静的メソッドから、よりLINQらしいIEnumerable<T>の拡張メソッドへと改良されています。
• SelectManyを利用した複雑な記述を、直感的で再利用性の高い単一メソッド呼び出しに置き換えることを目指します。

ツリー構造のような再帰的な階層を持つデータを、LINQを使ってフラットなリストに変換するためのFlatten()メソッドを考察・実装した記事です。当初は特定の型に依存する静的メソッドとして考案されましたが、よりLINQらしいアプローチとしてIEnumerable<T>の拡張メソッドに改良されました。これにより、SelectManyを再帰的に呼び出す複雑な定型コードが不要になり、可読性と再利用性を向上させる方法を提案しています。

Claude Sonnet 4.5 (Antigravity)

• ツリー構造をフラット化するLINQ拡張メソッドFlatten()の実装を紹介
• IEnumerable<T>の拡張として動作し、深さ優先探索でツリーを走査
• .NETランタイムへの追加提案も参照

ツリー構造をフラット化するLINQ拡張メソッドFlatten()の実装を紹介。IEnumerable<T>の拡張として動作し、深さ優先探索でツリーを走査します。.NETランタイムへの追加提案も参照されています。

GPT OSS 128B (Antigravity)

• 階層構造を深さ優先で平坦化する拡張メソッドを提供
• 任意の走査戦略をオプションで指定可能
• ツリー構造のデータをシンプルな列挙可能オブジェクトに変換

本稿では、IEnumerable<T> に対して再帰的に階層を走査し、単一のシーケンスに展開する Flatten メソッドの実装と使用例を解説しています。ジェネリック制約や戦略選択の実装詳細、サンプルコードを通じて実際のツリー型データの操作方法を示します。

• Extends IEnumerable<T> with a depth‑first flattening operation.
• Supports custom traversal strategies via an optional parameter.
• Shows practical usage with tree‑like data structures.

The piece presents an extension method that recursively flattens hierarchical collections into a single sequence. It explains the implementation details, including generic constraints and strategy selection, and provides example code illustrating how to traverse and output nodes from a custom tree structure.

Kiro で Serena を使う手順

Notebook LM

開発ツールである Amazon Kiro に AI 統合プラットフォームの Serena を導入し、効率的なコーディング環境を構築するための技術ガイドです。主な目的は、LSP（Language Server Protocol） を活用することで、AIエージェントによるコード編集の手順を簡略化し、トークン消費量を大幅に削減することにあります。

また、AIがプロジェクトの文脈を忘れてしまう問題に対し、ローカルメモリへの保存を通じて知識を補完する仕組みや、C#開発における具体的な注意点についても詳しく解説されています。最終的には、単なる自動化を超えた仕様駆動開発の重要性を説き、ツールを適切に組み合わせて開発精度を高める手法を提示しています。

GPT 5.2-Codex

• MCP サーバーの登録とステアリング設定の具体例
• uv/uvx を使った導入、プロジェクト登録とインデックス生成
• LSP 活用によるトークン削減の説明と推測メモ

VS Code 互換エディタでの MCP サーバー設定例を提示し、導入前提の uv/uvx インストールからプロジェクトのアクティベート、設定生成、インデックス作成までを順に整理している。ダッシュボードの挙動を抑える設定やピン止め方法にも触れ、C# 向けのステアリング指示の例を提示。後半は LSP による編集の効率化と、モデル側の記憶容量制限が体験に与える影響についての考察が続く。

Gemini 3 (Pro w/Antigravity)

• AIエディター「Kiro」において、MCPサーバー「Serena」をセットアップし、C#プロジェクトの開発効率を向上させる手順
• uvx を用いたSerenaの導入、プロジェクト設定（project.yml）、およびAgent SteeringによるAIの挙動制御
• Serena導入によるトークン節約効果や、Claude Codeの記憶容量制限に伴う性能低下（"アホになった"現象）への対策としての有効性

AI搭載のエディター環境である「Kiro」と、AIエージェントの記憶やコンテキスト管理を補助するMCPサーバー「Serena」を組み合わせ、C#開発環境を構築するための詳細な手順書です。単なるインストール手順だけでなく、ClaudeなどのLLMが直面している「コンテキスト制限による性能低下」という課題に対し、Serenaがどのように作用して開発体験（特にトークン効率や長期記憶の代替）を改善するかを考察しています。具体的には、Kiroの設定ファイル記述、Serenaを用いたプロジェクトのインデックス作成、そしてAIに適切なコード編集を行わせるための指示（Steering）設定など、実践的なノウハウが凝縮されています。また、C#固有のテスト駆動開発とAIの相性問題にも触れられています。

Gemini 3 (Auto w/CLI)

• Amazon Kiro環境において、MCPサーバー「Serena」をセットアップし連携させる具体的な手順。
• UVのインストールから設定ファイルの生成、プロジェクトのインデックス化までを解説。
• トークン節約効果や、仕様駆動開発における仕様書出力の有用性について考察。

Amazon Kiroエディターで、AIエージェントの記憶やファイル操作を補助する「Serena」を導入する方法をまとめています。MCP（Model Context Protocol）の設定を行い、コード生成におけるトークン消費の削減や、過去の文脈（仕様）の維持に役立つ点に言及。特にC#プロジェクトでの相性問題への対処や、仕様書生成によるメリットを詳述しています。

Gemini 2.5 (Auto w/CLI)

• AIコーディングエージェントSerenaをAmazon Kiro環境に統合するための具体的な設定手順を解説しています。
• MCPサーバー設定やAgent Steeringのカスタマイズ方法など、Kiro固有のセットアップに焦点を当てています。
• Serena導入によるトークン圧縮効果や、Claude Codeの性能に関する筆者の考察も述べられています。

AmazonのAIコーディングツールKiroで、外部のAIエージェントSerenaを連携させるための詳細なセットアップガイドです。Pythonのパッケージマネージャーuvのインストールから始まり、KiroのMCPサーバー設定やAgent SteeringのJSON構成、プロジェクトごとのインデックス作成まで、具体的なコマンドと設定例を交えて解説します。また、Serena導入がもたらすトークン圧縮のメリットや、AIエージェントの性能に関する著者自身の深い洞察も共有されています。

Claude Sonnet 4.5 (Antigravity)

• AI エージェント Serena を Amazon Kiro で C# プロジェクトに使用する手順を解説
• UV のインストール、Serena と Kiro の設定方法を詳細に説明
• トークン圧縮とメモリ管理の利点について言及

AI エージェント Serena を Amazon Kiro（VS Code 互換エディター）で C# プロジェクトに使用するためのセットアップ手順を詳細に解説。UV のインストールから、Serena と Kiro の設定、プロジェクト固有のセットアップまでカバーしています。

GPT OSS 128B (Antigravity)

• Serena のインストールから認証設定までを網羅
• 基本的なコマンド操作と設定手順を解説
• トラブルシューティングのポイントを提示

本チュートリアルでは、Kiro プラットフォーム上で Serena ツールチェーンを導入し、環境変数の設定や認証情報の登録、簡単なコマンド実行例を順に説明します。実際に動作確認できる手順を示し、よくある落とし穴と対策も併せて紹介しています。

• Guides the setup of Serena on the Kiro platform.
• Covers authentication, configuration, and basic commands.
• Highlights common pitfalls and troubleshooting tips.

In this tutorial, the author walks through the process of installing and configuring the Serena toolchain on Kiro. It details the required environment variables, command‑line interactions, and verification steps to ensure the system is ready for subsequent development tasks.

SIMD を使ってバイト列を 16 進数文字列に変換する

Notebook LM

ハッシュ化されたバイト列を効率的に16進数文字列へ変換する手法について、セキュリティとパフォーマンスの両面から考察した技術解説です。

検証プロセスにおいて元のデータを復元せず、UTF-8形式のハッシュ値のまま比較を行うことで無駄な処理を省くという設計思想の転換が提案されています。また、高速化の手段としてSIMD（並列演算）を用いた整数処理の歴史や特性に触れつつ、データサイズが小さい場合にはむしろ処理速度が低下するリスクがあることも示唆しています。

最終的にはUnity環境での制約を考慮したビット演算による実装例を提示し、アルゴリズムの選択と最適化のバランスを実地的な視点で説いています。

GPT 5.2-Codex

• 検証では元バイト列復元が不要という前提の整理
• Vector64 を使った変換の試行と効果の慎重な評価
• Unity 向けのビット演算版と大文字/小文字の扱い

検証用途では「復元」ではなく、16 進表現を UTF-8 として扱えば十分という見立てから入り、ベクトル化の実装を試す。Vector64 のシャッフルや条件選択で 4bit を文字化する流れを示す一方、効果は未検証で遅い可能性にも言及。Unity では intrinsics が使えないため、ビット演算で等価な実装を提示し、大小文字の選択や標準 API との整合確認も行っている。

Gemini 3 (Pro w/Antigravity)

• .NETの Vector64 を利用したSIMD命令により、バイト配列を高速に16進数文字列へ変換する実装例
• ビット演算と条件分岐（ConditionalSelectなど）を駆使し、一度に複数のバイトを処理して文字コードへマッピングする手法
• UnityなどSIMDが直接使えない環境向けの代替実装（unsafeとビット演算による最適化）も併せて紹介

ハッシュ値などのバイト列を可読な16進数文字列（Hex String）に変換する処理を、SIMD（Single Instruction, Multiple Data）命令を用いて並列化・高速化する試みです。従来の1バイトずつのループ処理ではなく、Vector64 を用いて8バイト（またはそれ以上）単位でまとめてデータをロードし、ナブルックアップや条件分岐をベクトル演算で行うことで、CPUの並列処理能力を活用するコードが提示されています。記事では、SIMD実装の詳細なコード解説に加え、SIMDが利用できないUnity環境向けに、ポインタと最適化されたビット演算を用いた実装も紹介されており、プラットフォームに応じたパフォーマンスチューニングの知見が得られます。SIMDの効果的な利用シーンについてのAIによる解説も引用されています。

Gemini 3 (Auto w/CLI)

• バイト配列を高速にHex文字列へ変換するため、Vector64を用いた並列処理を実装。
• .NETの標準機能やUnity環境での制約を考慮しつつ、ビット演算による効率化を図る。
• 処理速度向上は未検証ながら、低レベルなデータ操作の可読性と実装の楽しさに触れる。

ハッシュ値などのバイト列を可読性のある16進数文字列に変換する処理を、SIMD（Single Instruction, Multiple Data）命令を用いて最適化する試みです。C#のVector64を活用し、複数のバイトをまとめて処理するアルゴリズムを解説。UnityなどSIMDが直接使えない環境向けのビット演算による実装例も併せて紹介しています。

Gemini 2.5 (Auto w/CLI)

• ハッシュ値の検証において、元のバイト列を復元せず、ハッシュ文字列のバイト列表現を直接比較する手法を提案しています。
• .NETのVector64を用いたSIMD命令セットを活用し、バイト配列から16進数文字列への変換を高速化するコード例を提示しています。
• Unity環境向けに、SIMDが利用できない場合のビット演算による代替実装も紹介しています。

ハッシュ値の検証を効率化するアプローチとして、バイト列を16進数文字列に変換する処理の高速化に焦点を当てています。特に、.NETのSIMD(単一命令複数データ)機能を活用し、Vector64を使って複数のバイトを一度に処理する具体的なコードを解説します。これにより、パフォーマンスが重要な場面でのハッシュ検証処理のボトルネック解消を目指します。また、SIMDが利用できないUnityのような環境向けに、従来のビット演算を用いた実装方法も併せて紹介しており、様々な環境で応用可能な知識を提供します。

Claude Sonnet 4.5 (Antigravity)

• バイト配列を16進数文字列に変換する際のSIMD命令の活用方法を解説
• ハッシュ検証では元データの復元が不要な場合があることを指摘
• Vector64を使った高速化とUnity互換のビット演算版を紹介

バイト配列を16進数文字列に変換する際のSIMD命令の活用方法を解説。ハッシュ検証では元データの復元が不要な場合があることを示し、Vector64を使った高速化手法とUnity互換のビット演算版を紹介しています。

GPT OSS 128B (Antigravity)

• SIMD 命令を利用した高速な十六進変換を実装
• 従来の実装とベンチマークで性能比較
• .NET 用に再利用可能なユーティリティ関数を提供

本稿では、SIMD を活用してバイナリデータを十六進文字列へ変換する手法を解説します。ベクトル化による高速化の効果をベンチマークで示し、実際に使用できるヘルパーメソッドをコード例とともに提供しています。

• Demonstrates SIMD‑accelerated hex encoding.
• Compares performance against naïve implementations.
• Provides reusable utility functions for .NET.

The article explores how to leverage SIMD instructions to efficiently transform binary data into hexadecimal string representations. Benchmarks illustrate the speed gains, and the author supplies ready‑to‑use helper methods that can be integrated into performance‑critical applications.

AI にテストコードを書かせる前に知っておくべきこと【Gemini 編】

Notebook LM

Gemini CLI を活用して C# の自作データ構造である「HybridList」の単体テストを自動生成した実践記録と、その過程で得られた知見をまとめたものです。

著者は、AIを単なるコード生成器としてではなく「仕様書という曖昧な言語を解釈するエージェント」と定義し、Claude (Amazon Kiro) との比較を通じて Gemini の特性や限界を鋭く分析しています。特に、AIが無限ループに陥るのを防ぐために Debug.Assert をあえて指定する手法や、カバレッジ目標を戦略的に下げることで過剰なモック生成を回避するテクニックなど、実戦的なノウハウが具体的に示されています。

最終的に、AIに「何をすべきか」を主語・目的語まで明確に指示する重要性を説き、開発者が「面白い作業」に集中するための効率的な AI 協働スタイルを提案しています。

GPT 5.2-Codex

• 厳格なルールを付けた指示書の設計と、その副作用の観察
• Debug.Assert を選ぶ理由とレビュー負荷の最小化方針
• 不足テストや例外検証の抜けなど失敗例の整理

HybridList を題材に、詳細な指示書と逐次プロンプトで生成したコードを評価する記録。モック禁止やカバレッジ目標の意図、Debug.Assert による可読性の確保、例外テストや内部バッファ検証の抜けなど「指示の曖昧さが招いた不足」を列挙する。さらに Mermaid による仕様表現の有効性、モデル差による挙動、エージェントループの失敗パターンも含め、テスト生成前に整えるべき前提を具体化している。

Gemini 3 (Pro w/Antigravity)

• Gemini CLIを用いてC#の独自コレクションクラス HybridList の単体テストを自動生成させた知見とノウハウ
• AI生成コードの品質を保つため、Debug.Assert の強制やモック作成の禁止など、具体的かつ制約的なプロンプト設計の重要性
• KiroやClaudeと比較した際のGeminiの特性（指示待ち傾向）や、AIに仕様を理解させるためのMermaid記法の活用

コーディングエージェント（特にGemini）に複雑なロジックを持つC#クラスの単体テストを書かせる際の実践的な知見をまとめた記事です。単に「テストを書いて」と指示するだけでは品質の低いコードや無意味なモックが生成されてしまう問題に対し、DO NOTリストを用いた制約、Debug.Assert による検証スタイルの統一、実装の詳細ではなく「期待される動作」へのフォーカスなど、プロンプトエンジニアリングの観点から具体的な対策を提示しています。また、AIにアーキテクチャを正しく伝えるために自然言語よりもMermaid記法の図が有効である点や、カバレッジ目標を100%にしないことでAIの暴走（過剰なモック作成）を防ぐテクニックなど、AIペアプログラミングにおける実践的な制御手法が解説されています。

Gemini 3 (Auto w/CLI)

• 独自コレクションクラスの単体テスト生成を通じ、AIへの指示出しのノウハウを共有。
• モックライブラリの乱用や複雑なアサーションを避け、Debug.Assert等の単純な記述を推奨。
• テスト対象や方法を明確に言語化し、Mermaid記法で作図させるなどの工夫が有効。

Gemini CLIを用いてC#コードの単体テストを自動生成させた際の知見まとめです。AIが陥りやすい無限修正ループや不適切なモック生成を防ぐため、制約の強いプロンプト（DO NOT構文など）や、あえて単純なアサーションを使わせる戦略を解説。Kiroなどの他ツールとの比較も交え、AIに意図通りのテストを書かせるための要件定義の重要性を説いています。

Gemini 2.5 (Auto w/CLI)

• Debug.Assertのような単純なアサーションを指定することで、AIが複雑なテストライブラリの構文で混乱するのを防ぎます。
• 「関数カバレッジ以外は100%を目指さない」といったルールを設定し、AIが不要なモック作成や過剰なテストケース生成に陥るのを抑制します。
• 最初に曖昧な指示はせず、Mermaid記法などで構造を明確に伝え、AIのタスクを「単純なコード生成」に限定することが重要です。

AI、特にGeminiを使用してC#の単体テストを生成させる際の、具体的なプロンプトエンジニアリングと注意点を解説した実践的ガイドです。AIが生成するコードの品質を担保し、無限ループや不適切な修正を避けるためのルール設定（DO NOT構文の活用）や、テストの構成に関する明確な指示方法を提示します。この記事を読むことで、AIを単なるコード生成器としてではなく、制御された高品質なテストコードを記述させるためのパートナーとして活用するノウEハウを学べます。

Claude Sonnet 4.5 (Antigravity)

• Gemini CLI で C# プロジェクトの単体テストを生成する際の知見を共有
• Debug.Assertを使った簡潔なテスト手法を推奨
• AI への明示的な指示とアーキテクチャ図の重要性を強調

Gemini CLI を使って C# プロジェクトの単体テストを生成する際の知見を共有。Debug.Assertを使った簡潔なテスト、AI への明示的な指示の重要性、アーキテクチャ図の活用などを解説しています。

GPT OSS 128B (Antigravity)

• プロンプト設計のポイントとベストプラクティスを解説
• 生成されたテストコードの検証方法を提示
• CI パイプラインへの Gemini 連携手順を紹介

本稿では、Gemini を用いて自動テストコードを生成する際の注意点をまとめます。効果的なプロンプト作成手法、生成結果の品質チェック、CI に組み込む具体的なフローを示し、実務での活用を支援します。

• Discusses prompt engineering for test generation.
• Shows how to validate AI‑produced tests.
• Offers strategies to integrate Gemini into CI pipelines.

This piece delves into the considerations when using Gemini to automatically generate unit tests. It covers crafting effective prompts, ensuring the generated code aligns with project conventions, and automating the verification of test correctness within continuous integration workflows.

C# プロジェクトで Gemini CLI を使う

Notebook LM

C#プロジェクトにおいてGemini CLIを安全に動作させるためのサンドボックス環境の構築手法を解説した技術ガイドです。

特定のユーザー名設定が必須であることや、軽量なDebianイメージを採用して容量を抑えつつ**.NET環境を整えるための具体的な工夫が共有されています。環境変数を介さず、セットアップ済みのコンテナイメージ**として固定する運用の効率性が強調されており、開発者が実務で直面する技術的な制約と解決策を簡潔にまとめています。

GPT 5.2-Codex

• サンドボックス用の Dockerfile 設計と前提条件の整理
• Node ユーザー固定や .NET SDK 導入など運用上の注意点
• ビルド/実行コマンドとキャッシュ更新の手順

サンドボックス実行を想定したコンテナ構築の例として、Ubuntu をベースに npm/uv/.NET SDK を導入する Dockerfile を提示。ユーザー名が固定である点、Debian だと SDK 入手が難しい点、uv の導入とキャッシュ削除の扱いなど実務上の罠を整理している。ビルド時の --no-cache、実行時の --sandbox-image 指定など、CLI 利用者が迷いやすい箇所も明記している。

Gemini 3 (Pro w/Antigravity)

• C#プロジェクト開発用の WSL 上での Gemini CLI サンドボックス環境の構築手順
• Dockerfile による Node.js, gemini-cli, uv, .NET SDK のセットアップ
• コンテナ内での MCP サーバー（Serena）の設定とホスト環境への影響回避

C#プロジェクトでGemini CLI等のAIエージェントツールを安全かつ効率的に利用するための、WSL上のサンドボックス環境構築ガイドです。Node.jsやuv、.NET SDKを含むDockerイメージ（sandbox.Dockerfile）の作成方法から、コンテナ内でのMCPサーバー（Serena）の設定までを網羅しています。ホスト環境を汚さずにAIツールを試行錯誤するための実践的な手順がまとめられています。

Gemini 3 (Auto w/CLI)

• Dockerを用いて、Node.js環境が必要なGemini CLIをC#プロジェクトで利用するための構築手順。
• DebianやUbuntuベースのイメージに.NET SDKや必要なツールを組み込むDockerfile例。
• サンドボックス環境としてコンテナを活用し、安全にAIツールを実行する方法。

C#開発環境において、Node.js製のGemini CLIツールを安全かつ手軽に利用するためのDockerサンドボックス構築ガイドです。ユーザー権限の設定や.NET SDKのインストールを含むDockerfileの記述例を提示し、コンテナ内でCLIを実行するためのビルドおよび実行コマンドを紹介しています。

Gemini 2.5 (Auto w/CLI)

• C#/.NET開発環境を含むカスタムDockerイメージを構築する方法を解説しています。
• sandbox.Dockerfileの具体的な記述例を提供し、Debianベースでの軽量化やUbuntuベースでの簡単な環境構築について触れています。
• 作成したカスタムイメージをgemini -s --sandbox-image <image_name>のようにして利用する手順を示しています。

C#プロジェクトでGoogleのGemini CLIをサンドボックス環境内で安全かつ効率的に利用するためのガイドです。標準のサンドボックス環境には.NET SDKが含まれていないため、本記事では.NET SDKやその他の必要なツールをインストールしたカスタムDockerコンテナを構築する手順を詳細に説明します。提供されるDockerfileのサンプルを基に、開発者は自身のプロジェクト要件に合わせて環境をカスタマイズし、CLIツールを分離された安全な空間で実行できるようになります。

Claude Sonnet 4.5 (Antigravity)

• Gemini CLI のサンドボックス環境を Docker で構築する手順を紹介
• Debian/Ubuntu ベースで .NET SDK、Node.js、gemini-cli をインストール
• イメージのビルド・実行・更新方法を解説

Gemini CLI のサンドボックス環境を Docker で構築する手順を紹介。Debian/Ubuntu ベースで .NET SDK、Node.js、gemini-cli をインストールする Dockerfile と、イメージのビルド・実行方法を解説しています。

GPT OSS 128B (Antigravity)

• Gemini CLI のインストール手順を解説
• プロンプトからコード生成するフローを提示
• .NET ビルドプロセスへの組み込み方法を説明

本稿では、C# プロジェクトに Gemini コマンドラインツールを導入し、プロンプトからソースコードを生成する手順を示します。認証設定から実際のコード生成、MSBuild への自動化統合までを具体的に解説しています。

• Shows installation of the Gemini command‑line tool.
• Walks through generating code from prompts.
• Explains integration with .NET build processes.

In this guide, the reader learns how to incorporate the Gemini CLI into a C# development workflow. Steps include setting up authentication, invoking the tool to produce source files, and automating the generation step within MSBuild scripts.

vitest 風のテストフレームワーク

Notebook LM

FUnitは、JavaScriptで人気の高いVitestに強い影響を受けた、.NET 10およびUnity向けの革新的なユニットテストフレームワークです。

このツールは、AIエージェントによるテストコード生成を円滑に行うことを目的として設計されており、あえて機能を厳選したシンプルなアサーションライブラリを提供することで、AIによる曖昧な検証を防いでいます。

技術的には、C#のトップレベルステートメントを活用することでプロジェクトファイルを必要としない構造化テストを実現しており、GitHub Actionsとの親和性や高度な並列実行機能も備えています。Unity環境においてはメインスレッドの制御に注意が必要ですが、エディタ上だけでなく実行中のアプリ内でもテストが可能という、柔軟で実戦的な設計思想が貫かれています。

GPT 5.2-Codex

• 単一ファイル実行と describe/it 構文での運用例
• 同梱アサーションを絞ることでレビュー性を上げる意図
• Unity 上での並列実行とスレッド制約の注意点

単一ファイル実行に最適化した DSL 形式のテスト記述と、dnx による一括実行を紹介。GitHub Actions への Markdown 出力や、AI に書かせる前提で検証手段を限定した Must アサーションの思想が語られる。Unity でも動作するが、スレッドプール実行ゆえにメインスレッド制約がある点や、並列度の体感比較ログなど実践寄りの注意が含まれる。

Gemini 3 (Pro w/Antigravity)

• Vitest にインスパイアされた軽量かつ高速な C# 用単体テストフレームワーク「FUnit」
• .csproj 不要で単一ファイルとして実行可能なトップレベルステートメントの活用
• AI によるテスト生成を支援するアサーションライブラリ「Must」と GitHub Actions 連携

Vitestのような手軽さと高速なフィードバックを目指して開発された、C#向け単体テストフレームワーク「FUnit」の紹介です。.csprojファイル不要で単一ファイルとして実行可能な点や、トップレベルステートメントを活用したシンプルな記述スタイルが特徴です。Unity環境への対応や、AIによるテストコード生成を補助するアサーションライブラリ「Must」の同梱、GitHub Actionsでのレポート出力など、開発体験へのこだわりが解説されています。

Gemini 3 (Auto w/CLI)

• .NET 10の単一ファイル実行機能を活用し、csproj不要で動作する軽量テストツール「FUnit」。
• describe/it構文による構造化や、GitHub Actionsでのレポート出力にも対応。
• Unity環境でも動作し、非同期テストや並列実行もサポートする柔軟な設計。

JavaScriptのvitestに影響を受けた、C#向けの単体テストフレームワーク「FUnit」の紹介です。トップレベルステートメントを活用し、テストコード単体で実行可能な手軽さを実現。AIエージェントによるテスト生成を意識したシンプルなアサーションライブラリ「Must」や、Unityエディターおよびランタイムでの動作サポートについても解説しています。

Gemini 2.5 (Auto w/CLI)

• .NET 10の単一ファイル実行とトップレベルステートメントに最適化されており、.csproj無しでテストを記述できます。
• AIエージェントによるテストコード生成を意識し、同梱のアサーションライブラリは曖昧な比較を防ぐよう厳格に設計されています。
• Unityエディタやランタイムでも動作し、テストの並列実行による高速化もサポートしています。

vitestにインスパイアされたC#向けの新しい単体テストフレームワークFUnitの紹介です。現代的な.NETの機能を活用し、最小限のセットアップで構造化されたテストを記述できる手軽さを特長としています。GitHub Actionsとの連携機能も組み込まれており、CI/CDパイプライン上でのテスト結果の可視化も容易です。この記事では、FUnitの基本的な使い方から、Unityでの活用事例、そしてその内部の仕組みについての作者の考察まで、幅広く解説します。

Claude Sonnet 4.5 (Antigravity)

• C# 向けの単体テストフレームワーク「FUnit」を紹介
• vitest にインスパイアされ、.NET 10 最適化、Unity でも使用可能
• AI フレンドリーな Must アサーションライブラリを搭載

C# 向けの単体テストフレームワーク「FUnit」を紹介。vitest にインスパイアされた設計で、.NET 10 に最適化され Unity でも使用可能。シンプルな構造と AI フレンドリーな Must アサーションライブラリが特徴です。

GPT OSS 128B (Antigravity)

• Vitest に触発された軽量テストライブラリを紹介
• 主要なアサーションやモック機能を実装
• 非同期テストやスナップショットテストの例を提供

本記事では、JavaScript の Vitest の使い勝手を踏襲したテストフレームワークを実装し、その特徴と基本的な使用例を解説します。アサーション、モック、非同期テスト、スナップショット取得のサンプルコードを通じて、実際の開発での導入方法を示します。

• Introduces a lightweight testing library inspired by Vitest.
• Highlights syntax similarities with popular JavaScript frameworks.
• Provides examples for assertions and mocking.

The author presents a new testing framework that mirrors the ergonomics of Vitest while targeting a different runtime. Core features such as snapshot testing, mock utilities, and asynchronous test handling are demonstrated through concise code snippets.

「技術駆動パッケージング」を知ろう！

Notebook LM

ソフトウェア開発におけるフォルダ構成のあり方について、技術的なレイヤーで区切る技術駆動パッケージングをアンチパターンとして批判し、機能ごとにまとめる手法を推奨する解説記事です。

筆者はプロジェクトのディレクトリ構造を「最も頻繁に読まれるドキュメント」と定義し、一目で全体像が把握できる構造にすることの重要性を説いています。大規模なオープンソースプロジェクトの事例を引き合いに出しながら、硬直的な階層化が招くモノリシックな設計の弊害を指摘し、柔軟な設計を維持するための視点を提示しています。

最終的には、既存の設計パターンに固執するのではなく、依存関係の方向性を正しく制御することで、直感的かつ実用的なコード管理を目指すべきだと提案しています。

GPT 5.2-Codex

• フォルダー階層を「読まれるドキュメント」として捉える視点
• by feature 事例と、層分割が招く把握困難の指摘
• 名前空間や抽象の置き所で依存方向を制御する提案

フォルダー構成そのものが設計意図を伝えるという前提から、実例リポジトリを引き合いに階層分割の読みやすさを比較する。層分割を全面適用するとサブコンポーネントまで無理に揃えてしまう歪みが出る点や、機能単位での分割がスケールに強い点を論じる。さらに、依存方向の検出を名前空間で補助する案や、抽象をどこに置くかの考え方にも触れている。

Gemini 3 (Pro w/Antigravity)

• 「レイヤー駆動（Package by Layer）」と「機能駆動（Package by Feature）」の比較と考察
• フォルダ構造自体をドキュメントとして機能させるフラクタルなアーキテクチャの重要性
• Microsoft.Extensions.AI や Clean Architecture を例にした依存関係と凝集度の解説

ソフトウェアアーキテクチャにおけるフォルダ構成（パッケージング）について、「レイヤー駆動（Package by Layer）」の弊害と「機能駆動（Package by Feature）」の利点を比較・解説した記事です。フォルダ構造自体がドキュメントとして機能すべきという視点から、フラクタルな構成や凝集度の重要性を説いています。MicrosoftのライブラリやClean Architectureの誤解などを例に挙げ、保守性と可読性を高めるための具体的なディレクトリ構成案を提示しています。

Gemini 3 (Auto w/CLI)

• 機能単位ではなくレイヤー（技術）ごとにフォルダを分ける構成の弊害とアンチパターン性。
• GitHub Flow等の観点から、フォルダ構造自体をドキュメントとして機能させる重要性。
• マイクロソフトやGoogleのリポジトリ例を挙げ、機能単位のパッケージング（By Feature）を推奨。

Controller/Service/Repositoryのように技術的役割でフォルダを分ける「技術駆動パッケージング（Package by layer）」の問題点を指摘し、機能ごとにまとめる「Package by feature」の利点を説く記事です。フォルダ階層がドキュメントとしての役割も果たすべきという視点から、OSSの事例やクリーンアーキテクチャとの関連性を交えて解説しています。

Gemini 2.5 (Auto w/CLI)

• プロジェクトのフォルダ構造を「レイヤー（Infrastructure, Domain, UIなど）」ではなく「機能（Feature）」単位で分割するべきだと提案しています。
• 「技術駆動パッケージング」は、コンポーネント間の依存関係を複雑にし、プロジェクト全体の把握を困難にするアンチパターンだと指摘しています。
• Package by featureを採用している有名なOSS（ASP.NET Core, .NET Runtimeなど）を例に挙げ、その利点を解説しています。

ソフトウェアの保守性と可読性を高めるためのフォルダ構成戦略についての考察です。多くのプロジェクトで採用されがちな、レイヤー（UI, Application, Domain, Infrastructureなど）ごとにフォルダを分ける「技術駆動パッケージング（Package by layer）」の問題点を指摘し、その対案として機能単位で関心事をまとめる「Package by feature」を推奨します。なぜ後者の方が優れているのか、具体的なプロジェクト例を交えながらその思想的背景と実践的なメリットを掘り下げます。

Claude Sonnet 4.5 (Antigravity)

• 「技術駆動パッケージング（Package by layer）」をアンチパターンとして解説
• 「Package by Feature」を推奨し、フォルダ階層の重要性を強調
• TypeScript、Microsoft.Extensions.AI、ASP.NET Core などの実例を紹介

「技術駆動パッケージング（Package by layer）」をアンチパターンとして解説し、「Package by Feature」を推奨。フォルダ階層が重要なドキュメントであることを強調し、TypeScript、Microsoft.Extensions.AI、ASP.NET Core などの実例を紹介しています。

GPT OSS 128B (Antigravity)

• 最新技術を活用したパッケージング手法を定義
• バージョニングや依存管理のベストプラクティスを提示
• 実際のパッケージ事例を通じて効果を検証

本記事では、技術的に先進的な手法でライブラリやツールを配布する「技術駆動パッケージング」の概念と実践例を紹介します。バージョン戦略や依存関係の管理方法、実際のパッケージを例に効果を検証しています。

• Defines the concept of technology‑driven packaging.
• Explores benefits for library distribution.
• Provides a case study of a real‑world package.

The article explains a packaging philosophy that emphasizes leveraging cutting‑edge technologies to improve module delivery. It outlines best practices for versioning, dependency management, and publishing, illustrated with a concrete example.

Windows（WSL） + Codex CLI で Serena を使う手順

Notebook LM

Windows環境においてCodex CLIとSerena（MCPサーバー）を適切に連携させるための技術的な解決策を提示しています。

主な問題点は、ホストOS上でコマンドを実行すると、CLI本体とサーバー間のネットワーク通信に齟齬が生じてしまうという点にあります。この競合を回避するため、筆者はWSL（Windows Subsystem for Linux）内に閉じた開発環境を構築し、すべてのプロセスを同一の仮想環境下で実行することを推奨しています。Node.jsやツールのセットアップ手順から設定の共有方法までが網羅されており、GPT系ツールの利便性を向上させるための実践的なガイドとして構成されています。

GPT 5.2-Codex

• ループバック先の違いによる通信断絶の原因整理
• Linux 側での npm/uv 導入と設定共有の実務手順
• MCP 設定と起動方法、バージョン固定の注意

ホスト側から起動すると MCP サーバーが別環境で動き通信できないという落とし穴を説明し、Linux 側での実行に一本化する手順を提示している。npm/uv の導入、必要であれば .NET SDK の追加、設定フォルダのシンボリックリンクによる共通化など実務の手順が具体的。MCP の設定例や起動方法、Web ダッシュボード無効化の注意も添えられている。

Gemini 3 (Pro w/Antigravity)

• Windows 上の WSL 環境で Codex CLI と MCP サーバー（Serena）を連携させる手順
• ホストと WSL 間の localhost 通信問題を回避するための WSL 内完結構成
• Node.js, uv のインストールから設定ファイルのシンボリックリンク作成までの詳細

Windows上のWSL環境において、コーディングアシスタント「Codex CLI」とMCPサーバー「Serena」を連携させるためのセットアップ手順を解説しています。Windows側とWSL側のネットワーク通信の課題（localhost問題）を回避するため、すべてをWSL内で完結させる構成を推奨し、Node.jsやuvのインストールから、設定ファイルのシンボリックリンク作成、不要なWebダッシュボードの無効化まで、具体的なコマンドと共に手順を示しています。

Gemini 3 (Auto w/CLI)

• Windows環境でCodex CLIとMCPサーバーを連携させる際、WSL上で実行する必要がある点に注意。
• WSL内でのNode.js、Codex CLI、UVのインストールおよび設定ファイルの記述手順。
• WindowsとWSLで設定を共通化する方法や、実行時の注意点について解説。

Windows環境において、Codex CLIとMCPサーバー（Serena）を正しく連携させるためのトラブルシューティングです。PowerShellからの実行ではMCPサーバーがホスト側で起動し通信できない問題を回避するため、WSL環境内に実行環境を構築する手順をステップバイステップで説明しています。

Gemini 2.5 (Auto w/CLI)

• PowerShellからCodex CLIを実行すると、CLI本体はWSLで動作するが、MCPサーバーはホストOSで起動するため通信に失敗する問題を指摘しています。
• 解決策として、WSL環境内にCodex CLIと関連ツール（NPM, UV, Node.js）を直接セットアップし、WSLターミナルから実行する必要があることを解説しています。
• WSLとホストOS間でCodex CLIのアカウント設定を共通化するためのシンボリックリンク作成方法も紹介しています。

Windows Subsystem for Linux (WSL) 環境で、OpenAIのCodex CLIとAIエージェントSerenaを連携させる際に発生する特有のネットワーク問題とその解決策を提示する技術ガイドです。ホストOSとWSL間でのlocalhostの解釈の違いに起因する通信エラーを回避し、MCPサーバーを正しく機能させるための環境構築手順をステップバイステップで詳しく説明します。WSLで開発を行うユーザー必見のトラブルシューティング情報です。

Claude Sonnet 4.5 (Antigravity)

• Windows（WSL）環境で Codex CLI と Serena を使用する手順を解説
• PowerShell からの実行時の通信問題と解決策を説明
• WSL 内での完全なセットアップ手順を詳細に紹介

Windows（WSL）環境で Codex CLI と Serena を使用する手順を解説。PowerShell から実行すると WSL 上で動作するが、MCP サーバーがホスト OS で実行される問題と、WSL 内で完全にセットアップする解決策を紹介しています。

GPT OSS 128B (Antigravity)

• WSL 環境での前提条件とセットアップ手順を解説
• Codex CLI のインストールと Serena 連携方法を提示
• 基本的なコマンド例とワークフローを示す

本チュートリアルでは、Windows Subsystem for Linux 上に Codex CLI を導入し、Serena ツールチェーンと連携させる手順を詳述します。環境構築から実際のコマンド実行例まで、開発フローを一通り体験できるようにまとめています。

• Details environment preparation on Windows Subsystem for Linux.
• Shows how to install Codex CLI and configure Serena.
• Includes sample commands for typical workflows.

This tutorial walks through setting up a development environment that combines WSL, the Codex command‑line interface, and the Serena toolchain. It covers installation steps, path configuration, and execution of basic Serena commands.

端末に依存しない「ほぼ」正確な時刻を取得する

Notebook LM

ユーザーが端末時刻を意図的に操作してアプリ内のイベントを不正利用する問題を防ぐため、HTTPS接続のDateヘッダーから信頼性の高い時刻を取得する手法を解説しています。

従来のNTPは偽装のリスクがあるため、著者はUnity環境でSslStreamを用いた生のリクエストを行い、サーバーの証明書検証と併せて正確な時間を抽出する方法を提案しています。また、単発の取得だけでなく、一度得た時刻をベースに精度を維持するカスタム日付オブジェクトの実装や、証明書ピンニングによるセキュリティ強化の重要性についても深く考察されています。

最終的には、クライアント側での完全な偽装防止の難しさを認めつつも、アプリ層で現実的に可能な防御策を構造的にまとめた技術記事となっています。

GPT 5.2-Codex

• HTTPS の Date ヘッダーを使う発想と信頼性の整理
• Unity での HttpClient/UnityWebRequest の制約
• SslStream を使った最小構成と NetworkClock の設計

NTP に頼らず、HTTPS レスポンスの Date ヘッダーを基準にする方法を紹介。Unity では証明書検証まわりの API が期待通り動かないケースがあり、SslStream で HEAD を投げてヘッダーを取得する流れを示す。取得時刻にローカルの経過時間を足す NetworkClock の設計で問い合わせ回数を抑え、Roughtime や NTP 併用の話題も補足している。

Gemini 3 (Pro w/Antigravity)

• NTP を使わずに HTTPS レスポンスの Date ヘッダーから現在時刻を取得する手法
• Unity の HttpClientHandler キャッシュ問題を回避する SslStream を用いた実装
• ユーザーによる端末時計の操作（チート）への対策としてのサーバー時刻同期

ゲームや期間限定イベントなどで重要となる「正確な現在時刻」を、NTPサーバーを使わずにHTTPSレスポンスのDateヘッダーから取得する手法の紹介です。Unity環境特有のHttpClientHandlerのキャッシュ挙動による問題を回避するため、SslStreamを用いた低レイヤーな実装例（NetworkClockクラス）を提示しています。端末の時計変更チート対策として、手軽かつ実用的なサーバー時刻同期のアプローチを解説しています。

Gemini 3 (Auto w/CLI)

• NTPを使わず、HTTPSレスポンスのDateヘッダーを利用して信頼できる時刻を取得する手法。
• 取得した時刻と端末の稼働時間を組み合わせ、オフラインでも経過時間を計測する実装クラス。
• 通信経路の安全性や証明書の検証など、セキュリティ面での考慮事項についても言及。

ゲーム内イベントなどで端末時刻操作による不正を防ぐため、HTTPS通信のレスポンスヘッダーを用いてサーバー時刻を取得・利用する「NetworkClock」クラスの実装解説です。NTPを用いない理由や、Unity環境での証明書検証の制約、取得した時刻を起点にローカルで時間を刻む仕組みについて詳述しています。

Gemini 2.5 (Auto w/CLI)

• スマートフォンなどの端末時間を変更することによる不正行為を防ぐため、NTP以外の方法で信頼性のある時刻を取得するアプローチを提案します。
• 具体的な手法として、HTTPSレスポンスヘッダに含まれるDateフィールドの値を利用する方法を解説しています。
• Unity環境で標準のHttpClientが機能しない問題の回避策として、SslStreamを用いてHTTPリクエストを自前で実装し、時刻を取得するコード例を示しています。

オンラインゲームや時刻が重要なアプリケーションにおいて、ユーザーが端末の時刻設定を不正に操作することを防ぐための技術的な対策について論じます。NTP（Network Time Protocol）への依存を避け、より信頼性が高いと考えられるHTTPS通信のレスポンスヘッダから時刻情報を取得する方法を提案し、その具体的な実装方法をC#とUnityの文脈で解説します。さらに、証明書ピンニングなどのセキュリティ対策についても触れ、堅牢な時刻同期システムの構築に向けた考察を深めます。

Claude Sonnet 4.5 (Antigravity)

• デバイスのローカル時計に依存せず「ほぼ正確」な時刻を取得する方法を解説
• HTTPS レスポンスの Date ヘッダーを信頼できる時刻源として使用
• NetworkClock オブジェクトでローカル管理する手法を紹介

デバイスのローカル時計に依存せず「ほぼ正確」な時刻を取得する方法を解説。HTTPS レスポンスの Date ヘッダーを信頼できる時刻源として使用し、NetworkClock オブジェクトでローカル管理する手法を紹介しています。

GPT OSS 128B (Antigravity)

• クロスプラットフォームで高精度時刻取得を実現するライブラリを提供
• OS 毎の実装差分を抽象化し統一インターフェースを実装
• NTP との比較で精度を評価

本記事では、OS に依存せず高精度な現在時刻を取得できるライブラリを設計・実装し、その使用方法と精度評価を行います。各プラットフォームの実装差分を吸収し、NTP と比較した測定結果を示しています。

• Surveys methods for high‑precision time retrieval across platforms.
• Presents a cross‑platform library that abstracts OS differences.
• Evaluates accuracy against NTP references.

In this article, the author examines techniques for obtaining reliable timestamps without relying on system‑specific APIs. A portable library is introduced, offering a unified interface and demonstrating its precision through comparative testing.

埋め込み型 JSON シリアライザー

Notebook LM

Jsonableは、C#やUnityでの利用を想定した埋め込み型のJSONシリアライザー生成ツールであり、外部ライブラリへの依存を排除しながら高い実行パフォーマンスを実現することを目指しています。

このツールの最大の特徴は、メタデータをコメント形式で埋め込む独自の**.jsoncフォーマットを採用することで、データの先読みを不要にし、読み込み速度とメモリ効率を劇的に向上させている点にあります。ベンチマークによれば、特にデータの読み込みやインスタンスの再利用モードにおいて、既存のSystem.Text.JsonやJson.NETを凌駕する性能を発揮し、場合によってはバイナリ形式のMessagePackに匹敵する速度を叩き出します。

一方で、高速化のためにハッシュ値を用いたプロパティ判定や、書き出し時の特殊な文字数制限など、実用的なトレードオフを許容した設計がなされているのが特徴です。ソースコードが直接プロジェクトに組み込まれるため、ネットワーク同期やゲーム開発といった低遅延とポータビリティ**が求められる現場において、シンプルかつ強力な選択肢を提供しています。

GPT 5.2-Codex

• 型に ToJson/FromJson を直接生やす生成方式の特徴
• 各ライブラリとの速度/メモリ比較とキャッシュ効果
• jsonc 限定読み込みや Unity 向け挙動の注意

属性付与で型に出力・入力メソッドを生成し、外部シリアライザーへの依存を消すアプローチを説明。Json.NET/System.Text.Json/MessagePack とのベンチマーク比較、UTF-8 出力の配列再利用による高速化、読み込み時のアロケ削減など性能面のデータが中心。jsonc 限定という制約や、Unity 想定の .NET 5 では文字列処理が遅くなる点にも触れている。

Gemini 3 (Pro w/Antigravity)

• C# 用の埋め込み型 JSON シリアライザージェネレーター「Jsonable」の開発と性能計測
• データの先読みを不要にする独自の .jsonc (JMC1) フォーマットによるアロケーション削減
• MessagePack, System.Text.Json, Json.NET との詳細なベンチマーク比較

C#用の埋め込み型JSONシリアライザージェネレーター「Jsonable」の技術解説とパフォーマンス計測記事です。読み書きの高速化を目指し、特に読み込み時にはアロケーションを極小化する工夫が凝らされています。特徴として、データの先読みを回避するために独自の.jsonc（JSON with Metadata Comments）フォーマットを採用しており、要素数をメタデータとして埋め込むことでバイナリフォーマット並みの効率を実現する設計思想や、Unity環境でのベンチマーク結果が詳細に語られています。

Gemini 3 (Auto w/CLI)

• 外部依存なしでプロジェクトにソースコードとして組み込める軽量シリアライザー「Jsonable」。
• JSON with Comments (JSONC) 形式を採用し、メタデータ付与による読み込み高速化を実現。
• System.Text.JsonやMessagePackと比較し、特定のデータ構造で優れたパフォーマンスを発揮。

ソースコードジェネレーターを用いて型専用のシリアライズ処理を生成し、ランタイムライブラリへの依存を排除した「Jsonable」の紹介です。読み込み時の先読みを不要にする独自フォーマット（JSONC拡張）や、ハッシュ値によるプロパティ分岐などの最適化手法を解説。Unityでの利用やインスタンス再利用によるメモリ効率化についても触れています。

Gemini 2.5 (Auto w/CLI)

• 読み書き時に外部のシリアライザーインスタンスを必要とせず、myObj.ToJson()のようにオブジェクトから直接JSONを生成できます。
• 読み込みパフォーマンスは特に高速で、メモリ消費も少ないですが、入力形式としてコメント付きJSON(.jsonc)を要求するという制約があります。
• パフォーマンス向上のため、プロパティ名をハッシュ値で比較したり、書き込みヘルパーの呼び出しを最適化するなどの内部的な工夫が凝らされています。

Jsonableは、ソースジェネレーターを活用して、シリアライズ／デシリアライズのロジックを対象の型に直接埋め込むC#向けのライブラリです。これにより、Json.NETやSystem.Text.Jsonといった一般的なライブラリよりも高速なパフォーマンスを実現します。本記事では、その基本的な使い方から、他の主要なシリアライザーとの詳細なベンチマーク比較、そしてパフォーマンスを支える内部実装の技術的な詳細までを深く掘り下げて解説します。

Claude Sonnet 4.5 (Antigravity)

• 埋め込み型 JSON シリアライザー「Jsonable」を紹介
• myObj.ToJson() で直接 JSON を出力、シリアライザーへの依存が不要
• Json.NET や System.Text.Json より高速、.jsonc フォーマットで最適化

埋め込み型 JSON シリアライザー「Jsonable」を紹介。myObj.ToJson() で直接 JSON を出力でき、読み書き速度は Json.NET や System.Text.Json より高速。.jsonc フォーマットによるメタデータ付与で高速化を実現しています。

GPT OSS 128B (Antigravity)

• ソースジェネレータでコンパイル時に JSON シリアライズコードを生成
• リフレクションベースと比較した性能向上を実証
• 使用例とベンチマーク結果を提示

本稿では、C# のソースジェネレータを利用して型固有の JSON シリアライザーをコンパイル時に生成する手法を紹介します。リフレクションによる実装と比較した速度・メモリの改善をベンチマークで示し、実装例を提供しています。

• Implements a compile‑time JSON serializer using source generators.
• Reduces runtime overhead compared to reflection‑based approaches.
• Provides usage examples and performance metrics.

The piece introduces a JSON serialization library that generates type‑specific code at compile time. By avoiding reflection, the serializer achieves lower latency and memory usage, and the author supplies benchmarks to quantify the improvements.

AI の出力するコードが分かり辛い理由

Notebook LM

AIが生成するコードの不透明さを批判し、パブリックメソッドをオーケストレーション（指揮）に徹させるべきという設計哲学を論じたものです。

著者は、メインの処理が詳細なロジックを直接抱え込むのではなく、「何をどの順番で行うか」という段取りだけを記述し、具体的な振る舞いはプライベートメソッドやドメイン層へ委譲する構造を推奨しています。これにより、コードの可読性と保守性が向上し、開発者が全体像を即座に把握できる「クラスの顔」としての役割が明確になります。

最終的には、ドメイン駆動設計（DDD）の観点から、アプリケーション層は段取りを、ドメイン層はルールを担うという役割分担の重要性を解いています。

GPT 5.2-Codex

• 途中で処理を丸投げする構造の読みにくさを指摘
• 判断の集約と流れの明示を優先するスタイルを提示
• ローカル関数と NoInlining で肥大化を抑える案

中盤で別メソッドに完全委譲する形がレビュー負荷を高めるとして、公開メソッド内で判断と流れを完結させる方針を提案。シーケンス図で「分岐が外に散る」構造と「公開側に集約する」構造を対比し、レビュー対象の範囲を減らす狙いを説明する。必要ならローカル関数で実装を隔離し、呼び出し側の見通しを損なわない構成にするという補足もある。

Gemini 3 (Pro w/Antigravity)

• 「Public メソッドはオーケストレーションを心掛けよ」という原則に基づくコード設計論
• コンテキストを無視して細分化された純粋関数を生成する AI コードの問題点
• DDD におけるアプリケーションサービスの役割とロジック（演奏）の分離について

AIが生成するコードがなぜ読みづらく、保守しにくいのかを「Publicメソッドはオーケストレーションを心掛けよ」という設計原則の観点から考察しています。AIは文脈を無視した早期リターンや、無意味に分割された純粋関数を好む傾向があり、それが「処理の流れ（指揮）」と「具体的なロジック（演奏）」の混同を招いていると指摘。DDD（ドメイン駆動設計）におけるアプリケーションサービスの役割などを引き合いに、人間にとって理解しやすいコードの構造について論じています。

Gemini 3 (Auto w/CLI)

• AIが生成しがちな、判断と処理の委譲が混在するコードの可読性の低さを指摘。
• Publicメソッドは全体の流れ（オーケストレーション）に徹し、詳細はPrivateへ隠蔽すべきという設計論。
• DDDやクリーンアーキテクチャの観点から、責務の分離とコードの構造化についてAIに解説させる。

AIが生成するコードに見られる、早期リターンや処理の丸投げによる構造の分かりにくさを題材に、あるべきメソッド設計について考察しています。Publicメソッドを「指揮者」として定義し、具体的なロジックを隠蔽することで可読性と保守性を高める「オーケストレーション」の概念を、AIとの対話形式で深掘りしています。

Gemini 2.5 (Auto w/CLI)

• Publicメソッドが処理の全体像を示す「オーケストレーション」に徹しておらず、判断ロジックがPrivateメソッド内に分散してしまっている点を問題視しています。
• 理想的な構造として、Publicメソッドが全ての判断を行い、Privateメソッドはデータ処理などの具体的なタスクのみを実行する形を提案しています。
• このような構造にすることで、Publicメソッドのレビューだけでクラスの振る舞いを把握でき、Privateメソッドは単体テストで品質を担保すればよいというメリットが生まれます。

生成AIが書くコードは、なぜ人間にとって読みにくく、保守しづらいものになりがちなのか。その原因を「責務の分離」という観点から考察します。特に、クラスのPublicメソッドが「指揮者」としての役割を果たさず、ロジックの詳細に立ち入りすぎている点を問題として指摘します。この記事では、AIが生成した分かりにくいコード例と、それをリファクタリングした理想的なコード例を対比させながら、可読性と保守性を高めるための設計原則「Publicメソッドはオーケ-ストレーションを心掛けよ」を提唱します。

Claude Sonnet 4.5 (Antigravity)

• AI が出力するコードが分かりにくい理由を分析
• Public メソッドが処理を完全に委譲する問題点を指摘
• 「Public メソッドはオーケストレーションを心掛けよ」という設計原則を提案

AI が出力するコードが分かりにくい理由を分析。Public メソッドが処理を完全に委譲する問題点を指摘し、「Public メソッドはオーケストレーションを心掛けよ」という設計原則を提案。DDD の文脈での位置づけも解説しています。

GPT OSS 128B (Antigravity)

• 可読性が低くなる要因（命名・構造・コメント欠如）を分析
• 改善のためのプロンプト設計指針を提示
• 実例を交えてベストプラクティスを紹介

本稿では、生成系 AI が出力するコードの可読性が低下する典型的な要因を洗い出し、プロンプト設計や出力制御のベストプラクティスを提示します。具体的なコード例を通じて改善策を実演しています。

• Analyzes why AI‑generated code can be hard to read.
• Highlights issues like naming, structure, and lack of comments.
• Suggests best practices for prompting clearer output.

The author investigates common readability problems in code produced by large language models. By dissecting examples, the article identifies patterns that lead to confusing code and proposes prompt‑engineering techniques to encourage more maintainable results.

AI によるライブラリ生成の可能性：「TDoubles」開発から見えた課題と未来

Notebook LM

生成AIを活用して開発されたC#向けのモック生成ライブラリTDoublesの紹介と、その開発過程で浮き彫りになったAIによるコード生成の限界と教訓をまとめた技術記事です。

著者は、AIが関数型プログラミングのスタイルを好む一方で、状態管理や文脈の維持が困難であり、場当たり的な修正でコードの整合性を破壊する傾向があることを指摘しています。効率的な開発のためには、標準的なテストフレームワークよりもprintfデバッグによるフィードバック環境を整えることや、AIにドメインモデルを扱わせる工夫が重要であると説いています。

最終的に、AIはデータの受け流しには長けているものの、複雑なロジックの一貫性を保つには依然として人間の厳密な設計と監督が不可欠であることを示唆しています。

GPT 5.2-Codex

• 型安全なモック生成の設計とテストダブル別の使い分け
• 生成失敗の具体例と、原因としての状態管理/FP偏重
• 生成手順を抽象化した Blueprint 構想と学び

型安全なモックをソース生成で提供する構成を解説し、ジェネリック対応やコールバック機構、ダミー/スタブ/フェイク等の実装例を整理する。生成過程で発生した破壊的な修正やテストの形骸化などの失敗談を通じ、状態管理の弱さや関数型偏重がもたらす一貫性の欠如を分析。情報収集層と設計図層を分ける Blueprint 構想、printf デバッグやアナライザー活用の重要性も提示される。

Gemini 3 (Pro w/Antigravity)

• AI を活用して開発された C# 用モック生成ライブラリ「TDoubles」の技術解説
• AI の関数型プログラミング偏重が招く C# 等のステートフルな環境での文脈喪失問題
• TypeScript/JS エコシステムとの比較から見る AI コーディングの現状と限界

AI（Claude Sonnet 4.0等）を全面的に活用して開発されたC#用モック生成ライブラリ「TDoubles」の開発後記です。型安全なモック定義やpartial voidを用いたスパイ機能などのライブラリ概要に加え、開発プロセスで露呈した「AIは状態管理が苦手」「関数型プログラミングへの偏重による文脈の喪失」といった課題を深掘りしています。TypeScript/JSエコシステムとの対比を通じて、C#のようなステートフルな環境でのAIコーディングの限界と可能性を分析しています。

Gemini 3 (Auto w/CLI)

• AIによるC#ソースジェネレーター開発の失敗と成功から得られた、プロンプトエンジニアリングの教訓。
• 状態管理が苦手なAIに対し、コンテキストを限定しprintfデバッグを活用させる戦略。
• 関数型プログラミング的なコード生成傾向がC#プロジェクトにもたらす弊害についての考察。

AIエージェントを用いてモック生成ライブラリ「TDoubles」を開発した際の知見です。AIが複雑な状態管理や全体整合性の維持に失敗する傾向を分析し、テストフレームワークを使わずにログ出力でデバッグさせる手法や、データモデルと振る舞いを分離しがちなAIの癖（関数型指向）がC#に適さないケースについて論じています。

Gemini 2.5 (Auto w/CLI)

• TDoublesは、C#向けの型安全なモックを生成するソースジェネレーターで、その開発の90%をAIが担いました。
• AIは純粋関数を好み、状態管理が苦手なため、データモデルと関数を分離するスタイルでコードを生成しがちですが、これがC#のような環境では問題を引き起こすことを指摘しています。
• AIにコード生成させる際は、printfデバッグが可能な単純なテスト環境を用意し、テストフレームワークを使わせない方が結果的にうまくいくという教訓を共有しています。

生成AIを用いてC#のモックライブラリTDoublesを開発した経験を通じて、AIによるコード生成の現実的な課題と、そのポテンシャルを最大限に引き出すための実践的なノウハウを共有します。AIがOOPよりも関数型スタイルを好む傾向や、それに起因する問題点、そしてAIに品質の高いコードを生成させるための具体的なテスト戦略や環境構築の重要性について、実例を交えながら深く考察します。

Claude Sonnet 4.5 (Antigravity)

• AI によるライブラリ生成の可能性と課題を TDoubles 開発経験から考察
• AI の関数型プログラミング志向と状態管理の困難さを分析
• printf デバッグ環境の重要性とデータモデルではなくドメインモデルの必要性を指摘

AI によるライブラリ生成の可能性と課題を、C# モックジェネレーター「TDoubles」の開発経験から考察。AI の関数型プログラミング志向、状態管理の困難さ、コードの無意味化などの問題点を詳細に分析しています。

GPT OSS 128B (Antigravity)

• AI 補助で数値計算ライブラリを開発した経緯を紹介
• 設計一貫性やテスト自動化の課題を議論
• 今後の AI 活用展望と改善ポイントを示す

本記事は、AI を活用して数値計算ユーティリティ「TDoubles」を開発した経験をもとに、設計の一貫性やテスト自動化の課題を振り返ります。さらに、AI 補助開発の将来像と改善すべきポイントを展望しています。

• Chronicles the development of the TDoubles library using AI assistance.
• Discusses challenges such as design consistency and testing.
• Explores future directions for AI‑augmented library creation.

This narrative recounts the experience of building a numerical utilities library with the help of AI tools. It reflects on the workflow, pitfalls encountered, and how the collaboration shaped the project's architecture.

外部モジュールの静的リンクツール

Notebook LM

GitHubなどの外部リポジトリからファイルを直接取得し、プロジェクト内に取り込む疑似的な静的リンクを実現する.NETツールです。

単なるファイルコピーに留まらず、C#スクリプトのアクセス権限や名前空間を自動変換する機能を備えており、依存関係の競合を防ぎながらコードを統合できる点が大きな特徴です。特にGitHub Actionsとの親和性が高く、従来のgit submoduleに代わるシンプルで柔軟な外部モジュール管理の手法を提案しています。

開発者はこのツールを用いることで、複雑なトークン管理や条件分岐を排除し、クリーンで自動化されたプルリクエスト作成ワークフローを容易に構築することが可能になります。

GPT 5.2-Codex

• GitHub/URL からの取得と更新日時の扱いに対応
• 名前空間や可視性の書き換えなど C# 向けの編集機能
• Actions での運用や PR 自動化の小技を紹介

公開リポジトリや直リンクからファイルを収集し、必要に応じて C# の可視性や名前空間を変更して取り込めるツールを紹介。github: スキームで更新日時を取得し不要なコピーを避けられる点や、トークン設定によるレート制限緩和にも触れる。GitHub Actions での利用例、更新があれば PR を作る運用レシピも具体的に示している。

Gemini 3 (Pro w/Antigravity)

• 外部リポジトリや Gist のファイルをプロジェクトに静的リンク（コピー）する「static-import」
• C# ファイルの名前空間書き換えや public から internal へのアクセシビリティ変更機能
• GitHub Actions での自動同期と Pull Request 作成フローの構築

git submoduleの代替として、外部リポジトリやGistからソースコードをプロジェクト内に直接コピー（静的リンク）するためのCLIツール「static-import」の紹介です。単なるファイルコピーだけでなく、C#ファイルのnamespace書き換えやアクセシビリティ（public -> internal）変更機能を備えています。GitHub Actionsと組み合わせることで、別リポジトリの最新コードを自動同期し、Pull Requestを作成する運用フローも提案されています。

Gemini 3 (Auto w/CLI)

• 外部ファイルの取り込みとC#スクリプトの編集（名前空間変更など）を一括で行うdotnet tool。
• GitHubリポジトリからの取得や、APIトークンを用いたプライベートリポジトリへのアクセスに対応。
• GitHub Actionsでの利用を想定し、git submoduleの代替としてファイル集約を効率化。

git submoduleの代わりに、必要なソースコードファイルを直接プロジェクトにコピー・加工して取り込むCLIツール「static-import」の紹介です。GitHubやURLからのダウンロード機能に加え、取り込み時にinternal化や名前空間の書き換えを行う機能を搭載。CI/CDパイプラインでの活用例やPR作成の自動化についても触れています。

Gemini 2.5 (Auto w/CLI)

• xcopyやrobocopyのようにファイルをコピーする基本機能に加え、GitHubや任意のURLから直接ファイルをダウンロードする機能を持ちます。
• C#スクリプトを対象とした編集機能があり、コピー時にpublicな型をinternalに変更したり、名前空間を書き換えたりすることが可能です。
• GitHub Actionsのワークフロー内で利用することで、git submoduleの代替として、より柔軟に外部のソースコードをプロジェクトに取り込めます。

static-importは、外部のソースコードファイルを自身のプロジェクトに静的に取り込むための.NETグローバルツールです。単なるファイルコピーに留まらず、GitHubリポジトリや任意のURLからの直接ダウンロード、さらには取り込み時のコード整形（可視性や名前空間の変更）までサポートします。この記事では、static-importのインストール方法から、GitHub Actionsと連携させた実践的な利用例までを解説し、依存関係の管理をよりシンプルにするための一つの解を提示します。

Claude Sonnet 4.5 (Antigravity)

• 外部モジュールの静的リンクツール「static-import」を紹介
• GitHub や公開 URL からのダウンロード、C# スクリプトの編集機能を提供
• GitHub Actions での利用方法と PR 作成の簡単な方法を解説

外部モジュールの静的リンクツール「static-import」を紹介。GitHub や公開 URL からのダウンロード、C# スクリプトの編集機能（型のアクセス範囲・名前空間の変更）を提供し、GitHub Actions での利用方法も解説しています。

GPT OSS 128B (Antigravity)

• ネイティブバイナリを静的にリンクするユーティリティを提供
• プラットフォーム別設定とビルド手順を解説
• サンプルプロジェクトでの統合例を提示

本稿では、外部のネイティブモジュールをアプリケーションに静的リンクするツールの作り方と使用方法を解説します。プラットフォームごとの設定やビルド手順、サンプルプロジェクトでの組み込み例を示しています。

• Describes a utility for statically linking external binaries.
• Covers configuration, platform considerations, and build steps.
• Provides example integration with a sample project.

The article presents a tool that simplifies the process of embedding third‑party native libraries into an application binary. It walks through setting up linker flags, handling cross‑compilation, and verifying the final executable.

【.NET 10.0】 dnx 【Preview 6】

Notebook LM

.NET 10.0 Preview 6のリリースに伴う主要なアップデート内容と、開発者視点での実用的な考察をまとめた技術解説です。

特に注目されているのは、Node.jsのnpxのようにインストール不要でツールを実行できるdnxコマンドの導入や、単一パッケージで複数プラットフォームを支えるネイティブAOTの改善ですが、配布サイズや既存コマンドの制約といった課題も指摘されています。さらに、実行効率を高めるためのループ構造の最適化といった低レイヤーの変更点にも触れ、将来的な利便性と現状の限界を対比させています。

全体を通して、開発エコシステムの進化を歓迎しつつも、SDKの導入障壁やツールチェーンの成熟度を冷静に評価する構成となっています。

GPT 5.2-Codex

• インストール不要実行の導線と --yes の扱い
• 複数 RID 対応ツールの現状とパッケージングの課題
• while 最適化の裏側と手動適用の示唆

ツールの一時実行機能が追加されたが、初回確認やパッケージ名の扱いにクセがある点を整理。マルチ RID の AOT ツール配布については、dotnet pack 側の統合機能がまだ弱く、実際の運用に疑問が残ると指摘する。さらに JIT の while 最適化が改善される話題を紹介し、古い環境でも手動で寄せられる可能性に触れている。

Gemini 3 (Pro w/Antigravity)

• .NET 10.0 Preview 6 で導入されたツール実行コマンド「dnx」(dotnet tool exec)
• Native AOT ツールのパッケージング課題と配布サイズに関する考察
• コンパイラ最適化による while ループの if...do...while 変換とその効果

.NET 10.0 Preview 6で導入された新機能dnx（dotnet tool exec）についての速報記事です。Node.jsのnpxのように、ツールをインストールせずにパッケージ名指定だけで実行できる機能の使用感をレポートしています。併せて、Native AOTツールのパッケージングに関する現状の課題や、BCL（基本クラスライブラリ）全体に適用されるコンパイラのwhileループ最適化（if...do...while変換）というマニアックな変更点についても解説しています。

Gemini 3 (Auto w/CLI)

• .NET 10 Preview 6で追加された、ツールをインストールせずに実行できるdnxコマンド。
• npxライクな使い勝手と、NuGetパッケージからの直接実行による利便性と課題。
• 同時リリースのネイティブAOT対応や、コンパイラによるループ最適化の改善点。

.NET 10のプレビュー版で導入された新コマンドdnx（dotnet tool execのエイリアス的な機能）についての速報です。パッケージのインストール不要でツールを実行できる仕組みや、ネイティブAOTツールの配布に関する現状の課題、whileループのコンパイル結果における微細な最適化について解説しています。

Gemini 2.5 (Auto w/CLI)

• npxのように、dotnet toolをインストールせずに直接実行できるdnxコマンドが導入されました。
• 複数のRuntimeIdentifier（RID）を持つネイティブAOTツールを単一のNuGetパッケージとして公開できるようになりました。
• whileループが、内部でifとdo-whileを組み合わせたより効率的なコードにコンパイルされるよう最適化されました。

.NET 10.0 Preview 6のリリースノートを基に、開発者にとって特に注目すべき新機能や変更点をピックアップして解説します。パッケージ済みのCLIツールをインストール不要で実行できるdnxコマンドの導入、クロスプラットフォーム対応を容易にするネイティブAOTの改善、そしてコンパイラによるwhileループの最適化など、C#と.NETの未来を垣間見ることができる最新情報をお届けします。

Claude Sonnet 4.5 (Antigravity)

• .NET 10.0 Preview 6 の新機能を紹介
• dnx（npx 相当）によるパッケージ実行機能を解説
• ネイティブ AOT の複数 RID サポートと while ループの最適化を分析

.NET 10.0 Preview 6 の新機能を紹介。dnx（npx 相当）によるパッケージ実行、ネイティブ AOT の複数 RID サポート、while ループの最適化などを解説。実際の動作確認結果も含めて詳細に分析しています。

GPT OSS 128B (Antigravity)

• .NET 10 用の DNX プレビューランタイムの概要を紹介
• 簡単なプロジェクト作成手順を提示
• 新機能と既知の制限事項を解説

本記事では、.NET 10 向けプレビュー版 DNX ランタイムの目的と基本的な使用方法を解説します。プロジェクトの作成例や新機能、注意すべき制限事項をまとめています。

• Introduces the DNX runtime preview for .NET 10.
• Shows how to create and run a simple application.
• Highlights new features and known limitations.

In this preview‑focused piece, the author explains the purpose of the DNX runtime, demonstrates project scaffolding, and outlines the differences from previous .NET versions, providing guidance for early adopters.

ハッシュ値の検証と UTF-8 と SIMD

Notebook LM

UTF-8形式の16進数文字列をバイト列へ効率的に変換する方法を、.NETやUnity環境を対象に追求した技術記事です。

標準APIがReadOnlySpan<char>を要求し、生のUTF-8バイト列を直接扱えないという制約を背景に、ビット演算を用いた独自の高速な変換ロジックが提案されています。さらに、.NET 7以降で利用可能なSIMD（ベクトル化）による最適化手法を解説しつつ、UnityのBurstコンパイル環境における制限や実装の工夫についても触れています。

最終的に、ハッシュ値のようなバイナリデータには、Base64よりも構造が単純でベクトル化との相性が良い16進数表記が適していると結論付けています。

GPT 5.2-Codex

• 文字列ではなく生のバイト列から復元する必要性の整理
• ASCII のビット操作で 0-9/a-f を高速に変換する実装
• Vector64 でのベクトル化の試行と注意点

16 進表現の ASCII バイト列を直接バイト配列に変換する実装を提示し、Unity で標準 API が使いにくい点を背景にビット操作での変換手順を説明する。大文字小文字の扱いを | 0x20 で統一するテクニックや、2 文字を 1 バイトにまとめる手順を詳細に示す。Vector64 によるベクトル化案も試し、使い所の見極めに言及している。

Gemini 3 (Pro w/Antigravity)

• 16進数文字列から生の UTF-8 バイト列を介して直接バイト配列に変換する UnsafeConvertHexAsciiStringToBytes
• .NET 7+ の Vector64 (SIMD) を活用した高速化と、Unity 環境における制約と対策
• ハッシュ値表現に Base64 ではなく 16 進数が採用される理由と、Unity HttpClientHandler の仕様

ハッシュ値の検証などで必要となる「16進数文字列からバイト配列への変換」を、文字列（string）や char[] を経由せず、生の UTF-8 バイト列から直接かつ高速に行う手法を解説した記事です。基本的なビット演算による実装から、Vector64 を用いた SIMD 命令による並列化（ベクトル化）実装までを紹介し、コードの解説を行っています。また、Unity 環境での SIMD 利用の制限や、なぜハッシュ値には Base64 ではなく 16 進数が使われるのかという背景、.NET の API 設計に関する考察も含まれています。

Gemini 3 (Auto w/CLI)

• 16進数文字列（Hex）からバイト配列への変換を、SIMD命令を用いて高速化する実装。
• .NET標準APIがUTF-8バイト列を直接受け取れない問題への対処と、自前実装のアプローチ。
• Unity環境におけるVector64の利用制限や、Base64と比較した際のHex表記の優位性。

ハッシュ値などの検証において、UTF-8で表現された16進数文字列を効率的にバイト列へ変換する手法の解説です。Vector64を用いたSIMD実装による並列処理の最適化と、Unityなど制約のある環境での対応策、およびなぜBase64ではなく16進数が使われるのかという背景について考察しています。

Gemini 2.5 (Auto w/CLI)

• 16進数文字列のバイト列を、ReadOnlySpan<char>に変換せず、生のUTF-8バイト列から直接復元するUnsafeConvertHexAsciiStringToBytesメソッドを実装・解説しています。
• c | 0x20で大文字を小文字に統一し、ASCIIコードのオフセットを利用して高速に数値を計算するビット演算テクニックを紹介しています。
• .NET 7以降で利用可能なVector64を使い、SIMD(単一命令複数データ)を活用して16進数文字列からバイトへの変換処理をベクトル化する試みも行っています。

アセットのハッシュ値検証など、パフォーマンスが求められる場面で16進数文字列を効率的にバイト列へ変換する方法についての技術的な深掘りです。標準ライブラリが要求するchar配列への変換オーバーヘッドを避け、UTF-8バイト列から直接変換を行うカスタムメソッドの実装を解説します。さらに、SIMD命令を利用したベクトル化による究極のパフォーマンス最適化にも挑戦し、そのコードとロジックを詳しく紹介します。

Claude Sonnet 4.5 (Antigravity)

• ハッシュ値検証における UTF-8 バイト列の直接処理方法を解説
• 生の UTF-8 を渡せる 16 進数変換の実装と SIMD 対応版を紹介
• Base64 より 16 進数表記が適している理由を説明

ハッシュ値検証における UTF-8 バイト列の直接処理方法を解説。生の UTF-8 を渡せる 16 進数変換の実装、SIMD 対応版、Unity 互換版を紹介。Base64 より 16 進数表記が適している理由も説明しています。

GPT OSS 128B (Antigravity)

• SIMD を利用した高速ハッシュ計算手法を実装
• UTF-8 文字列のハッシュ化における注意点を整理
• ベンチマークで性能比較を提示

本稿では、SIMD 命令を活用した高速ハッシュ計算と、UTF-8 文字列を扱う際の課題を解説します。実装例とベンチマーク結果を通じて、パフォーマンス向上効果を示しています。

• Explores fast hash verification using SIMD instructions.
• Discusses UTF‑8 handling nuances in hashing.
• Offers benchmark results for various data sizes.

The author investigates techniques for accelerating hash computations by leveraging SIMD vectorization. The article also addresses challenges when processing UTF‑8 encoded strings and presents performance comparisons.

静的 DI コンテナー

Notebook LM

Unityにおける開発効率と安全性を高めるための自作フレームワーク、Dicon（静的DIコンテナー）とその周辺ツールについて解説されています。

このシステムは、実行時のエラーを避けるために依存関係をビルド前に静的に解決し、参照漏れをエラーとして検出することで、Unityオブジェクト特有のヌル参照問題を未然に防ぐことを目的としています。また、Diconは単なる検証ツールにとどまらず、AIによるコード生成を容易にするための実行プラットフォームとして設計されており、開発者が詳細な実装設定よりも機能そのものに集中できる環境を構築しています。

著者は、AIが理解しやすいシンプルな制約を設けることで、人間とAIが効率的に協調できるワークフローの重要性を強調しています。

GPT 5.2-Codex

• 参照未設定をコンパイル前に検出するための設計発想
• Dicon の Processor/Generator 仕組みと自動解決の流れ
• Addressables など動的ロードとの折り合いを検討

Unity のシリアライズ参照を事前に検証・解決するためのフレームワーク構想を紹介。NullReferenceReporter による検出、ComponentDependencyResolver による自動解決、ホワイトリスト運用など実例が示される。Processor/Generator の拡張点を設けることで、検証やコード生成を統一的に扱える狙いが語られ、Addressables の運用や非同期ロードとの整合も検討されている。

Gemini 3 (Pro w/Antigravity)

• SerializeField の参照をビルド時（AOT）に解決する Unity 用フレームワーク「Dicon」
• 実行時の動的解決を排し、Missing Reference を事前に検出する NullReferenceReporter
• AI によるコード生成を前提とした設計（Processor/Generator分離）と開発ワークフロー

Unity 開発において、コンポーネントの参照関係（依存関係）を動的な DI コンテナではなく、静的（AOT）に解決するための独自フレームワーク「Dicon」を紹介した記事です。SerializeField の未設定（null）をビルド前に検出するバリデーターや、階層構造から自動で参照を解決するリゾルバーの仕組みを解説しています。また、このツール自体が AI コード生成を前提に設計されており、複雑な処理を AI に任せるためのワークフローや、AI との協調開発における知見（処理と対象選択の分離など）についても語られています。

Gemini 3 (Auto w/CLI)

• UnityのSerializeFieldの参照を、実行時ではなくビルド前（静的）に解決・検証する仕組み。
• ヌル参照の検出や依存関係の自動解決を行い、ランタイムエラーを未然に防ぐ「Dicon」。
• AIによるコード生成や自動修復を前提とした、エラーを起こさせないための設計思想。

Unity開発において、Inspectorでの設定漏れや依存関係の解決をエディター上（静的）で行うフレームワーク「Dicon」の紹介です。実行時のFindやGetComponentを排除し、事前に参照を確定させることで安全性を向上。AIエージェントに修正を行わせやすい設計や、Roslynを用いない簡易ソース生成機能についても触れています。

Gemini 2.5 (Auto w/CLI)

• コンパイル時にSerializeFieldされたフィールドの参照が設定されているかを静的に検証し、未設定の場合はビルドエラーを発生させる仕組みを提案しています。
• Unityオブジェクトの参照を、命名規則（例: m_SubmitButtonからSubmitButton）に基づいてシーン階層から自動的に解決するComponentDependencyResolverを実装しています。
• Addressablesで管理されるアセットに対しても、事前に依存関係をダウンロードしておくことで、実行時の動的ロードを排除し、全ての参照を静的に解決するワークフローを想定しています。

Unity開発におけるNull参照問題をコンパイル時に撲滅することを目指す、新しいDI（依存性注入）コンセプAト「Dicon」の紹介です。実行時ではなく、ビルド前にコンポーネント間の依存関係を静的に解析・解決することで、MissingReferenceExceptionのリスクを根本から排除します。本記事では、その思想的背景から、実際にヌル参照を検出するNullReferenceReporterや、依存を自動解決するComponentDependencyResolverといった具体的な機能まで、詳細に解説します。

Claude Sonnet 4.5 (Antigravity)

• Unity オブジェクトの参照を静的に解決する DI コンテナー「Dicon」を紹介
• Processor/Generator を実行するプラットフォームとして設計
• ヌルチェック、依存解決、AI を活用したワークフローを実現

Unity オブジェクトの参照を静的に解決する DI コンテナー「Dicon」を紹介。Processor/Generator を実行するプラットフォームとして設計され、ヌルチェック、依存解決、AI を活用したワークフローを実現しています。

GPT OSS 128B (Antigravity)

• コンパイル時に依存関係を解決する DI コンテナーを実装
• ランタイムのリフレクションコストを排除
• 使用例と登録方法を提示

本記事では、コンパイル時に依存関係を解決する静的 DI コンテナーの実装方法を紹介します。リフレクションを排除した設計と、実際の登録・利用例を示しています。

• Presents a compile‑time dependency injection container.
• Eliminates reflection overhead for service resolution.
• Includes usage examples and integration steps.

This piece introduces a static DI framework that resolves dependencies at compile time, generating registration code to avoid runtime reflection. Sample code demonstrates registration and consumption patterns.

ZLinq に IEnumerable を実装したい

Notebook LM

ゼロアロケーションを目指すC#ライブラリ「ZLinq」に、標準のIEnumerableインタフェースを実装する試みとその意義について解説しています。

著者は、標準LINQが持つ遅延実行の利点（必要な分だけ処理し、メモリ消費を一定に抑える特性）がZLinqには欠けており、結果として特定の条件下で標準LINQよりもメモリ消費が増大する課題を指摘しています。検証の結果、最新の.NET 9で導入された特定の型制約の影響により実装が困難であるものの、.NET 8環境であればメモリ効率を劇的に改善しつつIEnumerableを統合できる可能性が示されました。

最終的に、パフォーマンスと利便性のバランスを考慮し、ライブラリの設計思想と実行プラットフォームの選択が重要であることを説いています。

GPT 5.2-Codex

• 遅延実行がもたらすメモリ特性の再確認
• 値列挙子を橋渡しするラッパー構造の提案
• .NET 8/9 の制約とベンチ結果の差異

遅延実行がメモリ消費やスパイクを抑える点を再確認し、値列挙をそのまま渡せない環境での性能ギャップをベンチで示す。値列挙子を IEnumerable に変換する薄いラッパーを提案し、インターフェイス越しでもアロケーションを抑えられる結果を提示。型制約の allows ref struct が影響するため、.NET 8 で成立しやすいという制約も述べている。

Gemini 3 (Pro w/Antigravity)

• ゼロアロケーション LINQ ライブラリ「ZLinq」への IEnumerable<T> 実装の試みとパフォーマンス検証
• 標準 LINQ の「遅延実行」による省メモリ効果と ZLinq の「即時評価」による特性の比較
• .NET 9 の allows ref struct 制約がもたらす構造体 IEnumerable 実装への影響

Cysharp 製のゼロアロケーション LINQ ライブラリ「ZLinq」に対して、標準 LINQ と互換性のある IEnumerable<T> インターフェースを実装する試みと、そのパフォーマンス検証をまとめた記事です。標準 LINQ の「遅延実行」による省メモリ効果と、ZLinq の「即時評価（ToArray）」によるスパイク負荷の違いをベンチマークで比較・分析しています。また、.NET のバージョン（特に ref struct 関連の制約）による実装の可否や、ZLinq 独自の ZLinqEnumerable を用いた場合のパフォーマンス特性についても詳細に議論されています。

Gemini 3 (Auto w/CLI)

• ゼロアロケーションを目指すZLinqに対し、遅延実行による省メモリ効果を狙ってIEnumerableを実装。
• ベンチマークによる比較で、特定条件下での標準LINQの優位性とZLinqの課題を分析。
• .NET 9のallows ref struct制約の影響と、.NET 8環境での回避策。

C#向けの高速LINQライブラリ「ZLinq」に、標準のIEnumerable<T>インターフェイスを実装する試みの記録です。即時実行によるメモリ消費のスパイクを避けるための遅延実行対応や、それによるパフォーマンスへの影響をベンチマークで検証。ref structに関する言語仕様の制約とその回避方法についても解説しています。

Gemini 2.5 (Auto w/CLI)

• 標準のLINQが持つ遅延実行の利点をZLinqで実現するため、IValueEnumerator<T>をラップするIEnumerable<T>実装を提案・実装しています。
• WhereとTakeのように遅延実行が有効なケースでは、ToArray()などで結果を即時評価する必要があるZLinqは標準LINQに比べて不利になることをベンチマークで示しています。
• 提案されたAsEnumerable()拡張メソッドを使うことで、ZLinqでもアロケーションを抑えつつ、外部APIへIEnumerable<T>として結果を渡せるようになります。

ゼロアロケーションを謳うLINQ実装「ZLinq」に、標準LINQの強力な機能であるIEnumerable<T>との互換性を持たせるための挑戦を記録した記事です。なぜIEnumerable<T>が重要なのかを遅延実行とメモリ効率の観点から解説し、ZLinqが苦手とするシナリオをベンチマークで明らかにします。その上で、ZLinqのIValueEnumerator<T>をラップしてIEnumerable<T>として振る舞わせる具体的な実装方法をコードと共に示し、両者の長所を融合させる可能性を探ります。

Claude Sonnet 4.5 (Antigravity)

• ZLinq に IEnumerable<T> を実装する方法を解説
• 標準 LINQ の遅延実行・省メモリの利点を活かす実装手法を紹介
• .NET 8 環境での実装とベンチマーク結果を詳細に分析

ZLinq に IEnumerable<T> を実装する方法を解説。標準 LINQ の遅延実行・省メモリの利点を活かしつつ、.NET 8 環境で allows ref struct を回避して実装する手法を紹介。ベンチマーク結果も詳細に分析しています。

GPT OSS 128B (Antigravity)

• カスタムイテラブルを ZLinq に適合させる手順を解説
• IEnumerable の実装例を提示
• パフォーマンスへの影響を評価

本稿では、独自のイテラブル型を ZLinq ライブラリで利用できるようにする方法を解説します。IEnumerable<T> の実装例と、クエリ実行時のパフォーマンス評価を行っています。

• Shows how to adapt ZLinq to work with custom iterables.
• Provides an implementation of IEnumerable<T> for ZLinq.
• Discusses performance implications.

The article details extending the ZLinq library to accept user‑defined enumerable types. It walks through implementing the required interfaces and evaluates the impact on query performance.

非同期メソッド内で Unity オブジェクトを正しくハンドリングする

Notebook LM

Unityにおける非同期処理では、await以降にオブジェクトが破棄されている可能性があるため、生存確認の再チェックが極めて重要です。

著者は、一般的によく使われるCancellationTokenが、Unityオブジェクトのメモリ管理やヌルチェックの代用としては必ずしも最適ではないと指摘し、単純なif文による存在確認の信頼性を説いています。この課題を効率的に解決するため、コードを自動解析して未確認のオブジェクトアクセスを検出するカスタムアナライザーの開発と導入手法が提案されています。

本書は、実行時エラーを防ぐための堅牢な実装パターンと、それをプロジェクト全体に普及させるための静的解析ツールの活用法を簡潔にまとめた技術解説です。

GPT 5.2-Codex

• await を跨ぐことで破棄済み参照になる危険の整理
• CancellationToken が万能でない理由と代替の考え方
• アナライザーによる検出と保守運用の工夫

await 後はフレームが進むため、対象が破棄されるケースを実例で示し、再確認が必要である点を強調する。CancellationToken を渡すと呼び出し側が実装詳細を知る必要が生じるため、単純な null チェックの方が信頼できるという結論を提示。検出支援としてアナライザーを作成し、await の位置やループの扱いで過検出が起きる点も含めて運用面の注意が述べられる。

Gemini 3 (Pro w/Antigravity)

• await 後のフレームで破棄済み Unity オブジェクトへアクセスする際の MissingReferenceException 回避
• CancellationToken では防げない問題に対し、単純な null チェックが有効である理由
• Roslyn アナライザーを用いた await 前後の this != null チェックの強制手法

Unity の非同期メソッド（async/await）において、await キーワードでフレームを跨いだ後に MonoBehaviour などの Unity オブジェクトにアクセスする際のリスクと対策を解説しています。CancellationToken を用いたキャンセル処理だけではオブジェクトの生存期間に関連する例外を防ぎきれないことを指摘し、シンプルに null チェックを行うことの優位性を説いています。また、このパターンを強制するために自作した Roslyn アナライザーの仕組みや、外部ライブラリ導入時の注意点についても触れています。

Gemini 3 (Auto w/CLI)

• 非同期処理中のUnityオブジェクト破棄によるアクセス違反を防ぐためのチェック手法。
• CancellationTokenの限界と、単純なヌルチェックの有効性についての再評価。
• 独自のRoslynアナライザーを用いた、安全なアクセスパターンの強制とコード品質向上。

Unityでの非同期処理（async/await）において、await後に破棄されたGameObjectやComponentへアクセスして発生するエラーへの対策です。CancellationTokenだけでは防ぎきれない問題を指摘し、this == nullチェックの重要性を解説。また、それを静的に検査するアナライザーの導入や、Unity 6のAwaitableによるメインスレッド復帰の利点についても触れています。

Gemini 2.5 (Auto w/CLI)

• awaitをまたぐと別フレームになる可能性があり、その間にUnityオブジェクトが破棄されている危険性を指摘しています。
• 解決策として、awaitの後にオブジェクトがnullでないかを再チェックする必要があることを解説しています。
• この問題を静的に検出するためのRoslynアナライザーを開発し、Unityオブジェクトへのアクセス前にif (this != null)のようなチェックを強制する仕組みを紹介しています。

Unityの非同期メソッド（async/await）でMonoBehaviourなどのUnityオブジェクトを扱う際に陥りがちなMissingReferenceExceptionを未然に防ぐためのベストプラクティスを解説します。awaitキーワードを挟むと実行コンテキストが中断・再開されるため、その間にオブジェクトが破棄される可能性があるという問題を掘り下げます。この記事では、その対策としてRoslynアナライザーを用いた静的解析を導入し、危険なコードをコンパイル時に警告・エラーとして検出する方法を提案します。

Claude Sonnet 4.5 (Antigravity)

• 非同期メソッド内で Unity オブジェクトを正しくハンドリングする方法を解説
• await 後の別フレームでの再チェックの必要性を指摘
• CancellationToken の限界とアナライザーによる解決策を紹介

非同期メソッド内で Unity オブジェクトを正しくハンドリングする方法を解説。await 後の別フレームでの再チェックの必要性、CancellationToken の限界、アナライザーによる解決策を紹介しています。

GPT OSS 128B (Antigravity)

• async メソッドでの Unity オブジェクト参照安全性を確保するパターンを提示
• キャンセルやコンテキスト切り替えの実装例を示す
• 主な落とし穴と回避策を解説

本記事では、非同期メソッド内で Unity のオブジェクトを安全に扱うためのベストプラクティスを紹介します。キャンセル処理やメインスレッドへの戻し方、典型的な落とし穴とその回避策を具体例で示しています。

• Explains safe patterns for accessing Unity objects in async code.
• Covers cancellation, context switching, and lifetime management.
• Provides code snippets for common scenarios.

In this guide, best practices for interacting with Unity engine objects from asynchronous methods are presented. Topics include ensuring object validity, avoiding race conditions, and integrating with Unity's main thread.

単体ソースジェネレーター

Notebook LM

FGeneratorは、記述が複雑でAIによる生成が不安定なRoslynソースジェネレーターの開発を、より確実かつ簡潔にするためのフレームワークです。

従来のAPIは専門知識が必要でハードルが高いという課題がありましたが、本作は宣言的APIを採用することで人間とAIの双方にとって理解しやすい単一ファイル構成を実現しています。この仕組みにより、開発者は煩雑な内部実装に悩まされることなく、特定のプロジェクトに特化した使い捨て感覚のジェネレーターをマクロのように手軽に作成できるようになります。

最終的に出力されるコードはUnity環境でも動作可能であり、専用のCLIツールを併用することで導入の手間も大幅に削減されています。

GPT 5.2-Codex

• 宣言的 API により生成処理を安定させる狙い
• 単一ファイルで完結する実装スタイルの例
• 属性検出や診断の扱いを簡潔にする設計

カオスな Roslyn API を避け、宣言的なベースクラスで生成処理を記述できるフレームワークを紹介。TargetAttributeName と Generate のみで対象選別と出力を行えるため、生成コードの意図が読みやすくなる。AutoNotify や StackArray などサンプルも示し、Unity 環境での incremental generator 動作に触れている。

Gemini 3 (Pro w/Antigravity)

• AI 向け Roslyn 宣言的 API フレームワーク「FGenerator」によるソースジェネレーター開発
• Roslyn API の複雑さを隠蔽し、属性定義と Generate 実装のみで完結する設計
• StackArray などのサンプル実装を通じた AI コード生成の実用性と使い捨て運用の提案

AI に Roslyn ソースジェネレーターを効率よく生成させるために開発されたフレームワーク「FGenerator」の解説記事です。Roslyn の API が複雑で AI が正しいコードを生成しにくいという問題に対し、FGenerator.Sdk を使用することで、属性定義と Generate メソッドの実装だけでソースジェネレーターを作成できることを示しています。また、INotifyPropertyChanged の自動実装や、構造体ベースのリストクラスなどの具体例を挙げ、AI に指示を出す際の「宣言的 API」の有効性や、使い捨て感覚でソースジェネレーターを作れる利点について論じています。

Gemini 3 (Auto w/CLI)

• AIにソースジェネレーターを作成させるための簡易フレームワーク「FGenerator」。
• 宣言的な記述により、複雑なRoslyn APIを隠蔽しAIの生成精度を向上。
• Unityプロジェクトでも手軽に利用できるビルド環境や、使い捨て可能な設計思想。

Roslyn APIの複雑さを隠蔽し、AIエージェントでも安定してC#ソースジェネレーターを作成できるようにするフレームワークの紹介です。単一ファイルで完結する設計や、Unityでの利用を想定したビルドツール、実際にAIに生成させたコード例（INotifyPropertyChangedの実装など）を通じて、開発効率向上の手法を提案しています。

Gemini 2.5 (Auto w/CLI)

• Roslynの複雑なAPIをラップし、Generateメソッドを実装するだけでソースジェネレーターを作成できる宣言的なAPIを提供します。
• ターゲットとなる型やアトリビュートをシンプルに指定でき、コード生成や診断メッセージの出力が直感的に行えます。
• Unityの2022.3.12以降にも対応しており、Unityプロジェクト固有のコード生成やコード規約チェックにも活用できます。

FGeneratorは、C#のソースジェネレーター開発の複雑さを劇的に低減させるためのフレームワークです。特に、生成AIにジェネレーターを開発させる際の生産性を高めることを目指して設計されています。本記事では、FGeneratorがいかにしてRoslyn APIの複雑さを隠蔽し、開発者がビジネスロジックに集中できるようにするのかを、INotifyPropertyChangedを自動実装するサンプルなどを通じて具体的に解説します。

Claude Sonnet 4.5 (Antigravity)

• 単一ファイルで動作する Roslyn ソースジェネレーター/アナライザーのフレームワーク「FGenerator」を紹介
• PoC に最適で、AI を活用した開発ワークフローに対応
• Unity 向けアナライザーの実装例も含む

単一ファイルで動作する Roslyn ソースジェネレーター/アナライザーのフレームワーク「FGenerator」を紹介。PoC に最適で、AI を活用した開発ワークフローに対応。Unity 向けアナライザーの実装例も含まれています。

GPT OSS 128B (Antigravity)

• 依存関係を持たない単体コード生成ユーティリティを実装
• ジェネレータのライフサイクルと出力例を提示
• 最小限の結合での利用方法を解説

本記事では、他のコードと結合度を極力抑えた単体ソースジェネレータの作り方を紹介します。ジェネレータのライフサイクル、生成コード例、最小限の依存での利用方法を示しています。

• Introduces a source generator that produces isolated code units.
• Discusses design considerations for minimal coupling.
• Includes a walkthrough of the generator's lifecycle.

This piece focuses on building a source generator that emits self‑contained snippets, emphasizing modularity and ease of integration into existing projects.

Roslyn を使って独自のディレクティブを実装する

Notebook LM

Unity環境における既存のコンパイル制限を打破するために、Roslynのソースジェネレーターを活用して独自の「includeディレクティブ」を構築する手法を解説しています。

主な目的は、外部のC#ファイルをプロジェクトの依存関係や参照設定に縛られることなく、相対パス指定によってソースコード内に直接取り込むことにあります。開発者はこの技術を用いることで、公式の言語仕様が未対応であるファイルの動的結合を擬似的に実現し、開発環境におけるインテリセンスの不具合や参照の手間といったストレスを解消できます。

最終的には、公式のアップデートを待つ間の実用的な代替案として、ソースジェネレーターによるメタプログラミングの柔軟性を提示しています。

GPT 5.2-Codex

• //:funit:include によるファイル取り込みの流れ
• 生成コードとして読み込むため参照制約を回避できる点
• 自己参照などの危険ケースと注意事項

単一ファイル実行の #: 指令が Unity では扱いづらい点を背景に、コメント形式の include をソース生成で再現する手法を説明する。指定ファイルをそのまま生成コードとして出力できるため、参照経路の制約を超えてテスト対象を取り込める。循環取り込みや同名衝突のリスク、incremental generator の診断周りに関する注意も述べられている。

Gemini 3 (Pro w/Antigravity)

• Unity プロジェクトでのファイル参照制約回避のための独自ディレクティブ #:package //:funit:include
• System.IO.File で外部ファイルを直接読み込み、ソースジェネレーター経由で展開する手法
• Visual Studio の IntelliSense と Unity コンパイルの両立を目指した過渡期的な解決策

.NET 10 の単一ファイル実行（#: ディレクティブ）が Unity でコンパイルエラーになる問題や、プロジェクト構成上の制約を回避するために、Roslyn ソースジェネレーターを使って独自のプリプロセッサーディレクティブ（のようなもの）を実装した話です。特に include ディレクティブによって、Unity プロジェクト外のファイルを相対パスで読み込み、ビルド時に展開することで、循環参照や依存関係を無視してコードを共有する力技のアプローチを紹介しています。

Gemini 3 (Auto w/CLI)

• C#ソースコード内で外部ファイルを直接取り込むincludeディレクティブの実装。
• ソースジェネレーターを活用し、プロジェクトの参照関係を越えたファイル共有を実現。
• Unityや単一ファイル実行環境における制約を回避するためのワークアラウンド。

C#の標準機能にはない#includeのような機能を、独自ディレクティブ（#:include）としてソースジェネレーターで実装する試みです。テストコードでの内部クラス参照や、Unityと.NETツールの過渡期におけるファイル共有の煩雑さを解消するためのソリューションとして提案しています。

Gemini 2.5 (Auto w/CLI)

• C#のソースコード内に//:funit:include <path>のようなカスタムディレクティブを記述できるようにします。
• ソースジェネレーター（IIncrementalGenerator）を用いてこのディレクティブを解析し、指定されたファイルをソースコードとして取り込みます。
• プロジェクト参照が複雑な場合や、Unityのテストスクリプトで外部ファイルを簡単に利用したい場合に、循環参照などを気にせずコードを共有できます。

C#の標準機能にはない、独自のプリプロセッサディレクティブをRoslynのソースジェネレーターを使って実現する方法を解説します。この記事では、FUnitというテストフレームワークのために実装された//:funit:includeディレクティブを例に、ソースコード内の特定のコメントを解析し、外部ファイルの内容をコンパイル時にインライン展開するテクニックを紹介します。これにより、プロジェクトの参照設定に手を加えることなく、柔軟にコードを共有する新たな道が開かれます。

Claude Sonnet 4.5 (Antigravity)

• Roslyn を使って独自のディレクティブ（#generator）を実装する方法を解説
• プリプロセッサーディレクティブの構文解析とソースジェネレーターへの統合を説明
• エラーハンドリングと実装の詳細を紹介

Roslyn を使って独自のディレクティブ（#generator）を実装する方法を解説。プリプロセッサーディレクティブの構文解析、ソースジェネレーターへの統合、エラーハンドリングなど、実装の詳細を紹介しています。

GPT OSS 128B (Antigravity)

• C# コンパイラに新しいプリプロセッサ指示を追加する手順を解説
• Roslyn API を用いた解析とコード生成例を提示
• 実装上の留意点とテスト方法を紹介

本稿では、Roslyn を利用してカスタムディレクティブをコンパイラに組み込む方法を解説します。指示の解析、コード生成、テストの実装例を示し、実装上の注意点をまとめています。

• Demonstrates creating a custom compiler directive with Roslyn.
• Shows how to parse and act on the directive during compilation.
• Provides a sample implementation and usage.

The author walks through extending the C# compiler by defining a new preprocessor‑like directive. Using Roslyn's APIs, the article illustrates parsing, validation, and code generation steps.

WSL をサンドボックス環境にする

Notebook LM

AIエージェントが安全にコードを実行できるサンドボックス環境をWSLで構築する手法を提案しています。

開発者は、構築の手間がかかるDockerの代わりにWSL自体を隔離環境として利用することで、C#プロジェクトなどの環境構築を簡略化し、ターミナルの操作性も維持しています。ホスト側のドライブへのアクセスを遮断しつつ、特定の作業フォルダのみをマウントすることで、AIによる自由なシステム操作と実データの保護を両立させています。

このアプローチは、複雑な設定を排除しながらAIオートパイロットの信頼性と利便性を高める実用的な解決策となっています。

GPT 5.2-Codex

• Docker 更新の手間を避けるための発想転換
• ホストドライブ遮断と作業フォルダーのみ共有する設計
• バッチ+PowerShell の起動スクリプト実装例

Windows でのコンテナ運用の不便さから、Linux 環境自体を隔離する方法を選ぶという提案。ホスト側ドライブの自動マウントを無効にし、起動フォルダーのみをマウントすることで作業範囲を限定する。バッチと PowerShell のポリグロットスクリプトで wsl.conf を設定し、空白を含むパスの制約など運用注意も細かく記載されている。

Gemini 3 (Pro w/Antigravity)

• AI エージェント用サンドボックスとしての、Docker 未使用 WSL 環境構築手法
• 起動用バッチファイルによるホストドライブ遮断と特定フォルダのマウント制御
• /etc/wsl.conf 自動書換えスクリプトによる automount 設定の管理

AI エージェント（コーディングエージェント）を Windows 環境で安全に利用するために、Docker コンテナの代わりに WSL 自体をサンドボックス化する手法を紹介しています。Docker イメージの管理の手間を省きつつ、AI がシステムを破壊しないよう、ホスト側のドライブへのアクセスを遮断し、作業対象のフォルダーのみをマウントして WSL を起動するバッチスクリプトを公開しています。永続化された環境で AI を試行錯誤させるための実用的なソリューションです。

Gemini 3 (Auto w/CLI)

• Dockerを使わず、WSL自体を使い捨て可能なサンドボックスとして構成する手法。
• 起動時にホスト側の重要ディレクトリへの書き込みを制限し、安全性を確保。
• バッチとPowerShellを組み合わせた起動スクリプトによる、手軽な環境構築と永続化。

AIエージェントやCLIツールの実行環境として、Dockerの代わりにWSL（Windows Subsystem for Linux）を活用する方法の解説です。WSL内からWindows側のファイルシステムへのアクセスを読み取り専用に制限するマウント設定や、それを自動化する起動スクリプトを紹介し、軽量かつ永続性のあるサンドボックス環境の構築を提案しています。

Gemini 2.5 (Auto w/CLI)

【生成されず】

Claude Sonnet 4.5 (Antigravity)

• WSL をサンドボックス環境として活用する方法を解説
• AI エージェントの実行環境として WSL を使用
• ホスト OS との分離によるセキュリティ向上と構築手順を紹介

WSL をサンドボックス環境として活用する方法を解説。AI エージェントの実行環境として WSL を使用し、ホスト OS との分離によるセキュリティ向上と、簡易的なサンドボックス環境の構築手順を紹介しています。

GPT OSS 128B (Antigravity)

• WSL 上で安全なサンドボックスを構築する手順を解説
• ファイルシステム・ネットワーク制限の設定方法を提示
• 簡易プロビジョニングスクリプトを提供

本チュートリアルでは、WSL を利用した開発用サンドボックスの構築手順を示します。ファイルシステムやネットワークの制限設定、すぐに使えるプロビジョニングスクリプトを提供しています。

• Guides setting up a secure sandbox using WSL.
• Covers filesystem isolation, network restrictions, and resource limits.
• Offers scripts for quick provisioning.

In this tutorial, the reader learns how to configure Windows Subsystem for Linux as an isolated development sandbox. Steps include configuring user namespaces, limiting network access, and automating environment setup.

Jules は最強のメンテナー説

Notebook LM

AIコーディングエージェントであるJulesを開発の保守フェーズに活用した際の知見をまとめた技術レビューです。

著者は、Julesを「Slackに常駐する専属メンテナー」のような存在と定義し、具体的なタスク指定やテストの実装において高い有用性を発揮する一方で、過剰な最適化や独自のコード書き換えといった制御の難しさについても言及しています。特にC#プロジェクトにおける挙動や、AIの暴走を防ぐための指示書（AGENTS.md）による制約の重要性が実体験に基づいて解説されています。

最終的に、GitHub上ではなくJulesのチャット内で完結させる運用スタイルが、「やりたくない作業」を自動化するツールとしての真価を引き出す鍵であると結論付けています。

GPT 5.2-Codex

• 長時間タスクや並列作業の運用感が良いという評価
• 強い最適化癖があるため制約書が必須という教訓
• タスク単位やセットアップ手順の癖を整理

ブラウザに残るタスクとして扱える点や、複数ブランチを並列に回せる点を保守フェーズ向きとして評価する一方、リファクタリング癖が強く無関係な変更が混入しがちな点を懸念する。強い制約を AGENTS.md に書く運用や、.NET 実行環境がタスクごとにリセットされる点など具体的なハマりどころを列挙。PR コメントを読めないためチャット完結が必須という運用面の注意も含む。

Gemini 3 (Pro w/Antigravity)

• AI エージェント「Jules」を既存 C# プロジェクトの保守メンテナーとして活用した評価
• 並列タスク開発フローと AGENTS.md による AI 行動指針（制約）の提示
• 過度な最適化やコードスタイル変更への懸念とドキュメントによる制御の重要性

GitHub Copilot Workspace の競合とも言える AI エージェント「Jules」を、既存の C# プロジェクトの保守運用に投入した際のレビュー記事です。チャットベースでタスクを依頼し、バックグラウンドで修正を行わせる体験を「専属メンテナー」と表現し、その有用性を高く評価しています。一方で、AI が勝手に行う過剰な最適化やコードスタイルの変更（フォーマット修正など）を抑制するために、プロジェクトルートに AGENTS.md を配置して指針を示すことの重要性や、具体的な指示内容の例も紹介しています。

Gemini 3 (Auto w/CLI)

• AIエージェント「Jules」を既存プロジェクトの保守・修正に活用した際の体験記。
• 具体的なタスク指示によるコード修正やテスト実装における高い有用性。
• 過剰な最適化や独自すぎるコードスタイルへの対処法（AGENTS.mdによる指示）。

GitHubのAIエージェント「Jules」を、新規開発ではなく既存コードのメンテナンスに投入した評価です。チャットベースでのタスク進行やブランチ管理の利便性を評価しつつ、勝手なコード書き換えやテスト無視といった挙動への対策として、明確なガイドライン（AGENTS.md）を設置する重要性を説いています。

Gemini 2.5 (Auto w/CLI)

• 既存コードのバグ修正やリファクタリング、テスト追加など、「作業内容が具体的」な保守タスクにおいて高いパフォーマンスを発揮します。
• 過剰な最適化や、C#の文脈を無視した強い思想に基づくコード書き換えを行う傾向があるため、AGENTS.mdのような明確な指示書で制約を与えることが重要です。
• タスクはブランチ単位で管理され、ブラウザを閉じても後で再開できるなど、非同期的なコミュニケーションで作業を進めるのに適したUXを提供します。

AIコーディングエージェント「Jules」を実際にC#プロジェクトのメンテナンスに利用してみた詳細なレビュー記事です。アクティブな新規開発よりも、既存リポジトリの保守や改善といったタスクでその真価を発揮するという筆者の見解を、具体的な成功例と失敗例を交えながら解説します。Julesを効果的に活用するためのプロンプトのコツや、その独特な挙動を制御するためのAGENTS.mdの活用法など、AIをチームの一員として迎えるための実践的な知見が満載です。

Claude Sonnet 4.5 (Antigravity)

• AI メンテナー「Jules」の可能性を考察
• コード生成だけでなく、Issue のトリアージ、PR レビュー、ドキュメント更新などを AI に任せる
• メンテナンス作業全般の自動化について議論

AI メンテナー「Jules」の可能性を考察。コード生成だけでなく、Issue のトリアージ、PR レビュー、ドキュメント更新など、メンテナンス作業全般を AI に任せる未来について議論しています。

GPT OSS 128B (Antigravity)

• メンテナンス自動化・テスト・ドキュメント化のベストプラクティスを提案
• 実際のプロジェクトでの効果測定結果を報告
• 導入手順とツールチェーンを紹介

本稿では、Jules 手法によるメンテナンス自動化の効果と実装例を紹介します。自動テスト・ドキュメント生成・CI 連携のベストプラクティスと、実際のプロジェクトでの効果測定結果を示しています。

• Argues for the superiority of the Jules maintenance approach.
• Highlights automation, testing, and documentation practices.
• Provides real‑world examples of its impact.

The article makes a case for adopting the Jules methodology in software maintenance, outlining its core principles and showcasing success stories.

【Unity】C# 標準ライブラリにもヒントが表示されるようにする【Rider / VS Code】

Notebook LM

Unity開発において、Visual StudioやVS Codeなどの外部エディタでC#標準ライブラリのヒント表示（IntelliSense）が欠落する問題を解消するための、エディタ拡張ツール「ApiDocumentationCollector」を解説する記事です。

このツールは、NuGetから適切なXMLドキュメントを自動で取得・配置することで、ライブラリの詳細な仕様や例外情報、Null許容に関する補足をコード上で直接確認できるようにします。導入にはUnity Package Managerを使用し、専用メニューから実行するだけで多言語対応のドキュメント環境が構築される仕組みです。

開発者がブラウザで公式リファレンスを検索する手間を省き、IDE上での開発効率を向上させることを主眼に置いています。

GPT 5.2-Codex

• XML ドキュメントを取得して参照アセンブリにコピーする仕組み
• 多言語ドキュメントのフォールバックと IDE ごとの表示差
• 権限昇格や容量要件など実行時の注意点

IDE の補足表示が不足しがちな環境向けに、XML ドキュメントをダウンロードして参照アセンブリへ配置するエディタ拡張を紹介。メニューから言語を選び、ダウンロードのみ/自動実行を切り替えるワークフローになっている。Rider/VS Code/Visual Studio それぞれの表示差や、コピー時の権限昇格、ディスク容量の見積りなど運用上のポイントもまとめられている。

Gemini 3 (Pro w/Antigravity)

• Unity プロジェクトで C# 標準ライブラリ (BCL) の XML ドキュメントを表示するエディター拡張
• ApiDocumentationCollector による XML ファイルの収集・配置と IntelliSense の改善
• Visual Studio, Rider, VS Code での挙動の違いと権限昇格を伴う自動セットアップ

Unity 開発環境（Visual Studio, Rider, VS Code）において、通常は表示されない C# 標準ライブラリ（mscorlib や System.*）の API ドキュメントコメント（XML ドキュメント）を表示させるためのツール「ApiDocumentationCollector」の紹介記事です。古い Unity バージョンや .NET Standard の過渡期的な構成によって失われていた API の詳細（例外や仕様の注釈）を IDE 上で確認できるようにするメリットを説き、ツールのインストール方法や、権限昇格を伴うファイルコピーの仕組みについて解説しています。

Gemini 3 (Auto w/CLI)

• Unityプロジェクトで欠落しがちな.NET標準ライブラリのXMLドキュメントを補完するツール。
• NuGetから各言語のドキュメントをダウンロードし、IDEでのIntelliSenseを有効化。
• 古いAPIの挙動やNull許容性などの重要情報をエディター上で確認可能にする。

Unity開発環境（Visual Studio, Rider, VS Code）において、System名前空間などの標準ライブラリのAPIドキュメントが表示されない問題を解決するエディター拡張の紹介です。NuGetからXMLドキュメントを取得・配置する仕組みや、それによって得られる開発効率の向上（仕様確認の手間削減など）について解説しています。

Gemini 2.5 (Auto w/CLI)

• Unityプロジェクトで開発していると表示されない、C#標準ライブラリ（BCL）のメソッドやクラスに関する詳細なドキュメントをIDE上に表示させます。
• NuGetから公式のドキュメントパッケージをダウンロードし、Unityエディタが参照するアセンブリに対応するXMLファイルを配置します。
• Visual Studio、Rider、VS Codeなど、主要なIDEで動作し、多言語（日本語、中国語、ドイツ語など）にも対応しています。

Unity開発環境における開発体験を向上させるためのエディタ拡張機能「ApiDocumentationCollector」の紹介です。通常、UnityプロジェクトではC#の標準クラスライブラリのAPIドキュメントがIDEに表示されませんが、このツールを使うことで、それらの詳細な説明やパラメータ情報、例外に関する注釈などをエディタ上で直接確認できるようになります。ツールのインストール方法から使い方、多言語対応の状況までを詳しく解説します。

Claude Sonnet 4.5 (Antigravity)

• Unity と Rider/VS Code で C# 標準ライブラリにもヒントが表示されるようにする設定方法を解説
• XML ドキュメントコメントの参照設定と NuGet パッケージの活用を紹介
• IDE 固有の設定方法を詳細に説明

Unity と Rider/VS Code で C# 標準ライブラリにもヒントが表示されるようにする設定方法を解説。XML ドキュメントコメントの参照設定、NuGet パッケージの活用、IDE 固有の設定などを紹介しています。

GPT OSS 128B (Antigravity)

• Rider と VS Code で Unity API の IntelliSense を拡張する設定手順を解説
• ヒント表示の有効化とトラブルシューティングを提示
• 実際の開発フローでの活用例を紹介

本記事では、Rider と VS Code において Unity の標準ライブラリに対するコードヒントを有効化する設定方法を解説します。設定手順、トラブルシューティング、実際の開発での活用例を示しています。

• Shows how to enable IntelliSense hints for Unity APIs.
• Covers configuration for Rider and VS Code.
• Includes troubleshooting tips.

This guide details steps to enhance code completion for Unity's C# libraries within popular IDEs, improving developer productivity by exposing hidden members and documentation.

GitHub Actions ワークフローをバッチスクリプトとして実行

Notebook LM

GitHub Actionsのワークフローをローカル環境で直接実行可能にするツールghx（GitHub eXecute）の活用方法と技術的背景を解説したものです。

開発者が慣れ親しんだワークフロー構文をそのままクロスプラットフォーム対応のバッチスクリプトとして利用することで、環境構築の簡素化やリソースの節約を実現する手法を提案しています。特に、WindowsとLinux間でのシェルスクリプトの差異を自動で吸収する変換機能や、マトリクス戦略による一括実行の仕組みについて詳しく記述されています。

最終的には、CI/CDの設定をローカルのビルドツールとして再利用することで、開発環境と自動化環境の一貫性を高めることを推奨しています。

GPT 5.2-Codex

• ワークフローの matrix 展開をローカル実行に変換
• Bash と CMD の差異を吸収する変換ルール
• 雛形生成や SHA ピン留めの補助機能

マトリクス展開されたジョブをそのままローカルで回すための変換ツールを紹介。uses 相当の再現、run の抽出、Windows 向けに CALL や ^ を使った変換、sleep の置き換えなど実務で必要な差分を吸収する。新規ワークフロー雛形の生成や、依存の SHA 固定を含めたテンプレート作成にも触れている。

Gemini 3 (Pro w/Antigravity)

• GitHub Actions ワークフローをローカル環境で実行可能にする CLI ツール「ghx」
• .yml ファイルを解析して Windows バッチファイル等のスクリプトに変換・実行する仕組み
• uses を無視し run コマンドのみを抽出することで、手軽にクロスプラットフォームなビルド環境を再現

GitHub Actions のワークフロー設定ファイル（.yml）を読み込み、ローカルマシン（Windows/macOS/Linux）上でバッチスクリプトとして実行できる CLI ツール「ghx」（GitHub eXecute）の紹介記事です。複雑な uses アクションは無視し、マトリクス展開や run コマンドの抽出に特化することで、Docker 等を使わずに手軽に CI 環境に近いビルドコマンドを再現・実行できることを強みとしています。Windows 環境特有のコマンド変換（bash -> cmd）の泥臭い実装や、Composite アクションへの対応状況についても解説しています。

Gemini 3 (Auto w/CLI)

• GitHub Actionsのワークフロー定義をローカル実行可能なバッチ/シェルスクリプトに変換するツール「ghx」。
• マトリクスビルドの展開や、クロスプラットフォームなコマンド実行の再現。
• 複合アクション（Composite Action）の記法を用いた、ローカル・CI共通のスクリプト管理。

GitHub ActionsのYAMLファイルを解析し、ローカル環境（Windows/Mac/Linux）で実行可能なスクリプトに変換するCLIツール「ghx」の紹介です。matrixによる複数環境のテストや、runステップのコマンド変換（BashからBatchへ等）を実現し、CI環境とローカル開発環境の差異を埋める手法を提案しています。

Gemini 2.5 (Auto w/CLI)

• GitHub Actionsのワークフローファイル（.yml）を解析し、ローカル環境で実行可能なバッチスクリプト（.batまたは.sh）に変換します。
• matrix戦略を解釈して複数のジョブを展開したり、runステップのコマンドをプラットフォーム（Windows/macOS/Linux）に合わせて適切に変換します。
• CI/CDパイプラインと同じロジックをローカルで簡単に再現できるため、ワークフローのデバッグやテストが効率的に行えます。

ghxは、GitHub Actionsのワークフローをローカルマシンで手軽に実行するための.NETグローバルツールです。クラウド上で実行する前に、手元の環境でワークフローの動作を確認したい、そんなニーズに応えます。この記事では、ghxのインストール方法、基本的な使い方、そしてWindows環境でBashスクリプトを互換性のあるバッチコマンドに変換する際の技術的な詳細について解説します。

Claude Sonnet 4.5 (Antigravity)

• GitHub Actions ワークフローをバッチスクリプトとして実行する方法を解説
• ローカル環境でのテストと CI/CD パイプラインの検証を実現
• スクリプト化による再利用性の向上を紹介

GitHub Actions ワークフローをバッチスクリプトとして実行する方法を解説。ローカル環境でのテスト、CI/CD パイプラインの検証、スクリプト化による再利用性の向上などを実現する手法を紹介しています。

GPT OSS 128B (Antigravity)

• GitHub Actions のステップをローカルバッチファイルに変換する手順を提示
• 環境変数やアーティファクトの取り扱いを解説
• 再利用可能なテンプレートを提供

本稿では、GitHub Actions のワークフローをローカルのバッチスクリプトとして実行できるよう変換する手順を紹介します。環境変数のマッピングやアーティファクト処理、再利用可能なテンプレートを提供しています。

• Demonstrates converting GitHub Actions steps into batch scripts.
• Explains environment variable mapping and artifact handling.
• Provides a reusable script template.

The article presents a method for extracting the logic of a GitHub Actions workflow into a standalone batch file, enabling local execution and debugging without the CI environment.

夢のソースジェネレーター

Notebook LM

「InjectableGenerator」は、AntigravityというAIツールを用いて開発された、ソースジェネレーターに独自の処理を注入できる試験的なライブラリです。

このツールは、複雑な構文解析を必要とするRoslynの壁を低くし、直感的なコード生成や独自のコーディング規約チェックをUnityを含む環境で実現することを目指しています。しかし、同一アセンブリ内でのアクセス制限やメモリ管理における技術的な課題が残るため、現時点では厳密な静的解析やルール検閲への活用が現実的であると示唆されています。

全体として、AIを活用してC#の開発体験をマクロのように簡装化しようとする、野心的な試行錯誤の記録となっています。

GPT 5.2-Codex

• アセンブリ属性で処理を注入するユニークな設計
• 診断メッセージ出力やソース生成の流れ
• 生成物へアクセスできないなど構造的な制約

アセンブリ属性で指定した型の静的メソッドが全型に対して呼ばれ、条件一致でソースを生成する仕組みを紹介。エラーや警告の発行にも対応し、IDE/Unity でも診断が出る点が特徴。一方で、解析側でコンパイルしたアセンブリを使うため生成物へのアクセスができない、ロードが増えるなど構造的な制約も詳述されている。

Gemini 3 (Pro w/Antigravity)

• ソースジェネレーター自体を動的に注入できるメタなソースジェネレーター「InjectableGenerator」
• [assembly: InjectableGenerator(typeof(...))] で指定したクラス内のメソッドをコンパイル時に実行
• 同じアセンブリ内のコード生成における制約（鶏と卵問題）や、AI（Antigravity）との共同開発体験

C# のマクロ機能の代替として、ソースジェネレーターに任意の処理（C# コード）を「注入」して実行させることができるライブラリ「InjectableGenerator」の紹介です。利用者が定義した Generate メソッドをソースジェネレーター側から呼び出すことで、簡易的なコード生成や規約チェックを実現します。しかし、同一アセンブリ内での型参照やコンパイルの仕組みに起因する技術的な限界（鶏と卵の問題）についても触れており、実用性には課題が残るとしています。また、開発に Google の AI "Antigravity" を活用した際の使用感についても言及しています。

Gemini 3 (Auto w/CLI)

• 外部から処理ロジックを注入できる、汎用的なソースジェネレーター「InjectableGenerator」。
• アセンブリ属性を用いて、任意の型に対してコード生成や検査を実行可能にする。
• Unity環境での動作対応や、AIを活用した開発プロセスについても言及。

ソースジェネレーター自体を再コンパイルすることなく、ユーザーコード側から生成ロジックを定義・注入できる「InjectableGenerator」の紹介です。簡易的なマクロのように機能し、コード規約チェックや定型コードの生成を柔軟に行える仕組みを解説。Google Antigravityを用いた開発体験についても触れています。

Gemini 2.5 (Auto w/CLI)

• [assembly: InjectableGenerator(typeof(...))] というアトリビュートを記述するだけで、指定したクラスのGenerateメソッドがソースジェネレーターとして機能します。
• Generateメソッドはアセンブリ内のすべての型を引数として受け取るため、リフレクションを用いて型情報を解析し、動的にコードを生成したり、コード規約をチェックしたりできます。
• Antigravity(GoogleのAI)を活用して開発され、Unity環境でも動作しますが、いくつかの技術的な制約も抱えています。

InjectableGeneratorは、ソースジェネレーター自体の開発をより簡単かつ動的に行うことを目指した、実験的なソースジェネレーターです。通常のソースジェネレーターがコンパイル時に静的にコードを生成するのに対し、このライブラリは「ジェネレーターのロジック」を外部から注入する、というメタ的なアプローチを取ります。本記事では、そのユニークな仕組みと使い方、そしてAIを活用した開発の舞台裏について紹介します。

Claude Sonnet 4.5 (Antigravity)

• ソースジェネレーターに処理を注入できる「InjectableGenerator」を紹介
• Unity 上でソース生成する際のコンパイルエラー問題を解決
• インメモリーコンパイルによる柔軟な開発ワークフローを実現

ソースジェネレーターに処理を注入できる「InjectableGenerator」を紹介。Unity 上でソース生成する際のコンパイルエラー問題を解決し、インメモリーコンパイルによる柔軟な開発ワークフローを実現しています。

GPT OSS 128B (Antigravity)

• 将来的にコード自動生成を大規模に実現するビジョンを提示
• アーキテクチャ設計と想定ユースケースを解説
• 初期プロトタイプのコード例を示す

本記事では、広範なコード自動生成を目指す「夢のソースジェネレーター」のコンセプトと設計方針を示します。アーキテクチャ概要、ユースケース、初期プロトタイプの実装例を紹介しています。

• Describes an ambitious source generator concept.
• Covers design goals, architecture, and potential use cases.
• Shares early prototype code.

In this speculative piece, the author outlines a visionary source generator that aims to automate repetitive coding patterns across projects, detailing its envisioned capabilities and challenges.

C# で Rust する

Notebook LM

Rustの特徴である所有権システムの本質を、C#エンジニアの視点から紐解き、その再現を試みた技術記事です。

著者は、Rustの革新性が「実体の移動」を前提とした暗黙的なムーブセマンティクスと、それをコンパイル時に静的チェックする仕組みにあると定義しています。C#において同様のメモリ安全性を目指す実験的実装として「RustSharp.cs」が紹介されていますが、言語仕様の差異から完全なコピーの制限やライフタイムの強制には限界があることも示されています。

最終的に、Rustの複雑な概念を単なるインスタンスとポインタの関係に置き換えて解釈することで、他言語の利用者がその設計思想を理解するための架け橋となっています。

GPT 5.2-Codex

• 所有権/借用を「移動渡し」として整理する説明
• 可変参照の同時禁止など制約の直感的解説
• 所有権を模倣するユーティリティの実装例

所有権の概念を「暗黙的な move」と捉える整理から入り、借用がポインタである点や可変参照の同時禁止などの特殊性を解説する。さらに、AbsoluteOwnership/Borrow を使って所有権移動を模した API を実装し、Move/Take の運用例を示す。言語機能で完全再現はできないことや、抜け穴の存在にも触れている。

Gemini 3 (Pro w/Antigravity)

• Rust の所有権システム（所有権、借用、移動）の概念的な解説と C# との対比
• C# で所有権モデルを模倣するためのクラス AbsoluteOwnership<T> と Borrow<T> の実装実験
• 言語レベルのサポートがない環境での所有権管理の限界（暗黙的コピーの防ぎようのなさ）

Rust の最大の特徴である「所有権システム」について、C# 開発者向けにわかりやすく噛み砕いて解説した記事です。Rust の挙動（すべてが移動渡し、借用はポインター、リソースの自動破棄）を説明した上で、それを C# 上で再現しようと試みた実験コード AbsoluteOwnership<T> を紹介しています。しかし、C# では暗黙的なコピー（値渡し）を言語仕様として防ぐことができないため、完全な再現は不可能であり、「運用でカバー」するしかないという結論に至っています。

Gemini 3 (Auto w/CLI)

• Rustの所有権システムの概念（移動、借用）をC#上で再現する試み。
• AbsoluteOwnership型などを用い、APIレベルで所有権の移動や貸与を模倣。
• C#の言語仕様上避けられないコピー（暗黙的な値渡し）による制限と抜け穴。

Rustのメモリ安全性の中核である「所有権」と「借用」の概念を、C#の型システムを使ってエミュレートする実験的な実装の解説です。読み取り専用フィールドやRef構造体を駆使して所有権の移動（ムーブ）を表現する方法と、どうしても防ぎきれないコピー作成などの言語的な限界について論じています。

Gemini 2.5 (Auto w/CLI)

• Rustの所有権（Ownership）と借用（Borrowing）の概念を、C#のstructとrefを活用して模倣する試みです。
• 所有権を表すAbsoluteOwnership<T>構造体を導入し、.Take()メソッドで所有権の移動を、.Move()で値の取り出しを表現します。
• C#の言語仕様上の制約から、変数のコピーを完全に防ぐことはできず、あくまで規約ベースでの運用に留まるという限界も示しています。

Rustの最も特徴的な機能である所有権システムを、C#でどこまで再現できるかに挑戦する思考実験的な記事です。ガベージコレクションに依存しないメモリ安全性をC#で実現するため、AbsoluteOwnership<T>やBorrow<T>といったカスタム構造体を定義し、Rustのコンパイラが静的に行うチェックを、API設計とコーディング規約によって擬似的に再現しようと試みます。この記事を通じて、両言語のメモリ管理に対する思想の違いを浮き彫りにします。

Claude Sonnet 4.5 (Antigravity)

• C# で Rust のような所有権システムを実現する試みを紹介
• ref struct、scoped、IDisposable などを活用したメモリ安全性の向上
• Rust との比較を含めた詳細な分析

C# で Rust のような所有権システムを実現する試みを紹介。ref struct、scoped、IDisposable などを活用し、メモリ安全性を高める手法を解説。Rust との比較も含めて詳細に分析しています。

GPT OSS 128B (Antigravity)

• Rust の所有権・借用概念を C# で模倣する手法を紹介
• 零コスト抽象化と安全性向上の実装例を提示
• パフォーマンスベンチマークを比較

本稿では、Rust の所有権や借用の概念を C# の言語機能で再現する方法を解説します。零コスト抽象化や安全性向上の実装例と、パフォーマンス比較ベンチマークを示しています。

• Explores Rust‑inspired patterns in C# code.
• Discusses ownership, borrowing, and zero‑cost abstractions.
• Provides example implementations.

The author draws parallels between Rust's safety guarantees and C# language features, presenting techniques to emulate ownership semantics and improve memory safety in managed code.

UPM パッケージのテストツール

Notebook LM

このツールは、Unity Package Manager向けのパッケージが複数のエディタバージョンで正しく動作するかを検証するため、最小構成のテスト環境を自動生成します。

開発者は対象のパッケージ設定を選択するだけで、依存関係を厳格に定義したクリーンなプロジェクト群を一括で作成し、ビルドの成否を効率的に確認することが可能です。現状はWindows環境におけるビルドテストの自動化に特化していますが、将来的にはユニットテストの自動実行など、さらなる機能拡張も視野に入れた設計となっています。

GPT 5.2-Codex

• 複数バージョン向けの最小プロジェクトを自動生成
• Built-in 依存を含めた manifest 設計が必須という注意
• 生成物の構成とビルド判定の考え方

Unity 向けパッケージのビルド確認を、複数バージョンの最小プロジェクトで一括実行するツールを紹介。最小構成ゆえに Built-in 依存まで manifest で明示する必要がある点を強調し、生成されるファイル構成やビルドスクリプトの内容を具体的に示す。ビルド成否の判定が exe の有無に依存する点や、テスト実行の自動化が今後の課題として挙げられている。

Gemini 3 (Pro w/Antigravity)

• Unity Package Manager (UPM) パッケージのビルドテストを自動化する「UpmPackageTestKit」
• サポート対象の Unity バージョンごとに最小構成のプロジェクトを自動生成して一括ビルド
• パッケージの一部のみを共有するような特殊な運用形態における依存関係チェックに有用

複数の Unity バージョンをサポートする UPM パッケージにおいて、クリーンな環境でのビルドテストを自動化するためのツール「UpmPackageTestKit」の紹介です。設定されたサポートバージョンに基づいて、最小構成の Unity プロジェクト（manifest.json とビルドスクリプトのみ）を自動生成し、Windows 向けのビルドを一括で実行することで、依存関係の不足やバージョン固有のエラーを検出します。特に、パッケージ全体ではなく一部の機能を切り出して提供するような運用において効果を発揮します。

Gemini 3 (Auto w/CLI)

• 複数のUnityバージョンに対応した最小構成のテスト用プロジェクトを自動生成するツール。
• 依存パッケージのみを読み込むクリーンな環境でのビルドテストを実現。
• CLIビルドスクリプトの生成により、CI/CDパイプラインやローカルでの一括検証を効率化。

Unity Package Manager (UPM) パッケージの開発において、サポートする複数のUnityバージョンでの動作確認を自動化する「UpmPackageTestKit」の紹介です。特定のパッケージのみを含む空のプロジェクトを生成し、Windows向けのビルドを実行することで、依存関係の不足やバージョン固有のエラーを検出する仕組みを解説しています。

Gemini 2.5 (Auto w/CLI)

• 指定したpackage.jsonを基に、複数のUnityバージョンに対応した最小構成のテスト用Unityプロジェクトを自動生成します。
• 生成されるプロジェクトは、テスト対象のパッケージとビルドスクリプトのみを含むクリーンな環境で、依存関係の競合などを排除してビルドテストを実行できます。
• 内蔵のビルドスクリプトは、Windows向けにIL2CPPでのビルドを自動で行い、ビルドの成否をチェックします。

UpmPackageTestKitは、自作のUnity Package Manager (UPM) パッケージの互換性を、複数のUnityバージョンにわたって効率的にテストするためのエディタ拡張ツールです。異なるUnityバージョンごとにクリーンなテストプロジェクトを手動でセットアップする手間を省き、ワンクリックで複数バージョンのプロジェクト生成とビルドテストの実行を可能にします。本記事では、このツールの導入方法から具体的な使用手順までを解説します。

Claude Sonnet 4.5 (Antigravity)

• UPM パッケージのテストツールを紹介
• Unity Package Manager 向けのパッケージ開発時のテスト自動化を実現
• CI/CD 統合とバージョン管理を効率化するワークフローを解説

UPM パッケージのテストツールを紹介。Unity Package Manager 向けのパッケージ開発時に、テストの自動化、CI/CD 統合、バージョン管理などを効率化するツールとワークフローを解説しています。

GPT OSS 128B (Antigravity)

• Unity Package Manager 用のテストフレームワークを提供
• ユニット・統合・パフォーマンステストを網羅
• CI への組み込み例と実行方法を提示

本稿では、UPM パッケージ向けに設計されたテストツールを紹介します。ユニットテスト、統合テスト、パフォーマンステストの実装例と、CI パイプラインへの組み込み手順を示しています。

• Introduces a testing framework for Unity Package Manager packages.
• Supports unit, integration, and performance tests.
• Shows CI integration examples.

The article presents a toolset designed to validate UPM packages, offering a suite of tests that can be run locally or in CI pipelines to ensure package reliability.

おわりに

振り返ってみると、今年は「AI を使ってコード生成するのが趣味です」って感じでした。

諸々やって得た結論としては、

• AI は付きっきりで面倒見てもまともなソースを生成できない
  • AI によるライブラリ生成の可能性：「TDoubles」開発から見えた課題と未来
• 握るべきコントロールは握り、他は担当者（AI エージェント）に任せる／信頼する（してないけど）
  • AI の出力するコードが分かり辛い理由
• WSL を使った簡易サンドボックス[^3] は便利
  • WSL をサンドボックス環境にする

という感じです。

まともにソースコードが生成できなかった頃から一年弱で大分進化しました。

• VS Code + Gemini コードアシストがめっちゃ便利

今年は手書きで「すげー高速に動作する（ハズの）メッセージングライブラリー」なんかも作ったんですが、

そういうヤツはそこそこに、AI の生成したソースばっか読んでいた気がします。

--

まとめに含まれていない投稿

• 依存性の注入（DI）と Unity
  • これに繋がる 👉 静的 DI コンテナー
• 【Unity 6 対応】MonoBehaviour ライフサイクルの実行条件
• 古い C# 環境でも Task.WhenEach を使いたい
• VS Code + Gemini コードアシストがめっちゃ便利
• 便利なスクリプトの詰め合わせ【Unity／.NET】

--

AI の使い過ぎで投稿数がスゴイです。

以上です。それでは良いお年を。