C#未経験の僕がAIに読めるコードを書かせるまで

C#Kaigi2026の登壇資料です。
https://csharpkaigi.net/talks/lt-ai-readable-code

Transcript

1. C#未経験の僕がAIに読める コードを書かせるまで マグロ/佐々木陽貴 2026/9/19 C#Kaigi
2. 自己紹介 名前:マグロ/佐々木陽貴(sasaki haruki) 所属:株式会社くふうカンパニー Twitter:sigumataityouda GitHub:maguro-alternative コメント:基本ruby,ts,go書いてます。
3. 未経験でもC#が扱える時代に 昨今のAIエージェント情勢で細かい言語仕様を知らなくても扱えるように
4. ただし認知負債は貯まる こちらが認識できるのは側だけ 中身のブラックボックス化は徐々に進んでいく
5. 読めるようにしよう 読める=意図通りか検証できるようにすること - ASTで縛って読めるコードを書かせる BDDによる振る舞いの検証
6. 例 例として「避けゲー」を作る - 画面の上から落ちてくる敵を左右に動いて避ける 生き残った時間だけスコアが増える
7. 読めるコードを書かせる まず読める定義を測る - C#の基本文法を徹底的に見て、気になったものは調べる or AIに聞く - たまにクイズ形式で AIに問題出してもらってそれを解くみたいなこともした
8. 読めるコードを書かせる わかったこと - 基本文法は問題なし。 public sealed class UserRepository : IUserRepository { private readonly IDbConnection _connection; public async Task<IReadOnlyList<User>> FindActiveAsync( CancellationToken cancellationToken = default) { ... } }
9. 読めるコードを書かせる わかったこと - 基本文法は問題なし。 宣言が他言語より長いが中身 が簡潔 public sealed class UserRepository : IUserRepository { private readonly IDbConnection _connection; public async Task<IReadOnlyList<User>> FindActiveAsync( CancellationToken cancellationToken = default) { ... } }
10. 読めるコードを書かせる ハマった点 - LINQによる遅延評価 - 画面外にいった敵を消して追加する var onScreen = enemies.Where(e => e.Y > bottomY); enemies.Add(new Enemy(...)) if (onScreen.Count() > 10) { ... } ここで追加した敵は onScreenに含まれな いと思ってた。
11. 読めるコードを書かせる ハマった点 - LINQによる遅延評価 - 画面外にいった敵を消して追加する var onScreen = enemies.Where(e => e.Y > bottomY); enemies.Add(new Enemy(...)) if (onScreen.Count() > 10) { ... } 遅延評価が入るので 追加した敵も対象とな る
12. 読めるコードを書かせる ハマった点 - LINQによる遅延評価 - 他言語だと明示的に書かないと基本遅延操作にならない (Ruby:lazy,TS/JS:function*) ORMではよく採用されるけど、 console使っているとついつい忘れる var onScreen = enemies.Where(e => e.Y > bottomY); enemies.Add(new Enemy(...)) if (onScreen.Count() > 10) { ... }
13. 読めるコードを書かせる ハマった点 - LINQによる遅延評価 - 遅延評価を辞めさせて、結果を必ず返す方式にする var onScreen = enemies.Where(e => e.Y > bottomY).ToList();
14. 読めるコードを書かせる ハマった点 - 拡張メソッド - そもそもなんだこれ 既存クラスに新たにメソッドを追加できるもの public static class EnemyExtensions { public static bool IsThreatening(this Enemy enemy, Player player) { return enemy.IsAlive && enemy.DistanceTo(player) < 5f; } } Enemyを直接いじらず にIsThreateningを追加
15. 読めるコードを書かせる ハマった点 - 拡張メソッド - 変に依存が増えて全体像が追いづらくなるため使用を避ける public static class EnemyExtensions { public static bool IsThreatening(this Enemy enemy, Player player) { return enemy.IsAlive && enemy.DistanceTo(player) < 5f; } }
16. 読めるコードを書かせる 禁止する方法 書かれたらコンパイルエラーで落とす
17. 読めるコードを書かせる 禁止する方法 書かれたらコンパイルエラーで落とす ASTを弄って落とすようにする 基本文法は問題なく読めたのでASTも問題なく読めると判断
18. 読めるコードを書かせる LINQ 結果を必ず返すようにする (他にも条件があるものの)とりあえずこの3つが分かれば良い 代入、戻り値の部分 か？ メソッドが LINQ のも のか？ 戻り値が遅延型か？
19. 読めるコードを書かせる LINQ 代入、戻り値の部分か？ context.RegisterSyntaxNodeAction(AnalyzeLocalDeclaration, SyntaxKind.LocalDeclarationStatement); context.RegisterSyntaxNodeAction(AnalyzeFieldDeclaration, SyntaxKind.FieldDeclaration); context.RegisterSyntaxNodeAction(AnalyzeAssignment, SyntaxKind.SimpleAssignmentExpression); context.RegisterSyntaxNodeAction(AnalyzeReturn, SyntaxKind.ReturnStatement); context.RegisterSyntaxNodeAction(AnalyzeArrowBody, SyntaxKind.ArrowExpressionClause);
20. 読めるコードを書かせる LINQ private static bool IsLinqOperator(IMethodSymbol method) LINQ のメソッドか判定 { INamedTypeSymbol containing = method.ContainingType; if (containing == null || containing.ContainingNamespace == null) { return false; } if (containing.ContainingNamespace.ToDisplayString() != "System.Linq") { return false; } return containing.Name == "Enumerable" || containing.Name == "Queryable";
21. 読めるコードを書かせる 遅延型かどうか LINQ if (definition.SpecialType == SpecialType.System_Collections_Generic_IEnumerable_T || definition.SpecialType == SpecialType.System_Collections_IEnumerable) { return true; } if (definition.ContainingNamespace != null && definition.ContainingNamespace.ToDisplayString() == "System.Linq") { return definition.Name == "IOrderedEnumerable" || definition.Name == "IQueryable" || definition.Name == "IOrderedQueryable";
22. 読めるコードを書かせる 禁止する方法 書かれたらコンパイルエラーで落とす ASTを弄って落とすようにする 基本文法は問題なく読めたのでASTも問題なく読めると判断 →条件式の塊なので全然読める
23. 振る舞いの検証 動作が正しいか検証する必要もある 実際にプレイするのもありだけど正直限界もあるので自動テストも入れる でもどこまで検証すればいい？
24. 振る舞いの検証 こうあってほしいと言うストーリー像がある ユーザーストーリーを立ててそれを元にテストを組み立てる BDDを採用
25. 振る舞いの検証 BDD(振る舞い駆動開発) システムの振る舞いを中心に捉える手法 Gherkin記法を使うことで自然言語を元にテストを組むことができる
26. 振る舞いの検証 例：プレイヤーがどれだけ粘るか ストーリー：生き残った時間でスコアが増える Given:ラウンドが始まったとき、スコアは 0 When:時間が経つ Then:スコアが増える
27. 振る舞いの検証 ストーリー通り組めるのでわかりやすい public void GrowsWithSurvivedTime() { // Given ラウンドが始まり、スコアは 0 Score score = new Score(); // When 2 秒生き残る score.Advance(2f); // Then スコアは 1 秒あたり 10 ずつ増え、20 になる Assert.AreEqual(20, score.Value); }
28. 結果 自分の想定通りのコードになるので読みやすくはなった。 理解が追いつかない部分も機械的に落とすようになっているので、認知負荷の軽減に は繋がっている。
29. 結果 また敢えて禁止したものがどういった課題を解決するのかを認識できた。 なので結果的にC#学習の補助になった。 ※以前はLINQ自体を禁止してたけど徐々にわかってきたので部分的に解放してる
30. 課題 Unity周りの認知負債がたまりやすい - Unityの属性 MonoBehaviour シーンの入れ替え... Unity側を薄くして振る舞い見てるけど、Unityが丸々負債と化すのでこの辺もどうにかしたいところ...
31. まとめ - 読みづらいものはASTで縛ろう 検証に困ったら振る舞いに注目してみる