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

C#未経験の僕がAIに読めるコードを書かせるまでマグロ/佐々木陽貴 2026/9/19 C#Kaigi

自己紹介名前:マグロ/佐々木陽貴(sasaki haruki) 所属:株式会社くふうカンパニー Twitter:sigumataityouda GitHub:maguro-alternative コメント:基本ruby,ts,go書いてます。

未経験でもC#が扱える時代に昨今のAIエージェント情勢で細かい言語仕様を知らなくても扱えるように

ただし認知負債は貯まるこちらが認識できるのは側だけ中身のブラックボックス化は徐々に進んでいく

読めるようにしよう読める=意図通りか検証できるようにすること - ASTで縛って読めるコードを書かせる BDDによる振る舞いの検証

例例として「避けゲー」を作る - 画面の上から落ちてくる敵を左右に動いて避ける生き残った時間だけスコアが増える

読めるコードを書かせるまず読める定義を測る - C#の基本文法を徹底的に見て、気になったものは調べる or AIに聞く - たまにクイズ形式で AIに問題出してもらってそれを解くみたいなこともした

読めるコードを書かせるわかったこと - 基本文法は問題なし。 public sealed class UserRepository : IUserRepository
{ private readonly IDbConnection _connection; public async Task<IReadOnlyList<User>> FindActiveAsync( CancellationToken cancellationToken = default) { ... } }

読めるコードを書かせるわかったこと - 基本文法は問題なし。宣言が他言語より長いが中身が簡潔 public sealed class UserRepository
: IUserRepository { private readonly IDbConnection _connection; public async Task<IReadOnlyList<User>> FindActiveAsync( CancellationToken cancellationToken = default) { ... } }

読めるコードを書かせるハマった点 - LINQによる遅延評価 - 画面外にいった敵を消して追加する var onScreen = enemies.Where(e
=> e.Y > bottomY); enemies.Add(new Enemy(...)) if (onScreen.Count() > 10) { ... } ここで追加した敵は onScreenに含まれないと思ってた。

読めるコードを書かせるハマった点 - LINQによる遅延評価 - 画面外にいった敵を消して追加する var onScreen = enemies.Where(e
=> e.Y > bottomY); enemies.Add(new Enemy(...)) if (onScreen.Count() > 10) { ... } 遅延評価が入るので追加した敵も対象となる

読めるコードを書かせるハマった点 - LINQによる遅延評価 - 他言語だと明示的に書かないと基本遅延操作にならない (Ruby:lazy,TS/JS:function*) ORMではよく採用されるけど、 console使っているとついつい忘れる var
onScreen = enemies.Where(e => e.Y > bottomY); enemies.Add(new Enemy(...)) if (onScreen.Count() > 10) { ... }

読めるコードを書かせるハマった点 - LINQによる遅延評価 - 遅延評価を辞めさせて、結果を必ず返す方式にする var onScreen = enemies.Where(e
=> e.Y > bottomY).ToList();

読めるコードを書かせるハマった点 - 拡張メソッド - そもそもなんだこれ既存クラスに新たにメソッドを追加できるもの public static class
EnemyExtensions { public static bool IsThreatening(this Enemy enemy, Player player) { return enemy.IsAlive && enemy.DistanceTo(player) < 5f; } } Enemyを直接いじらずにIsThreateningを追加

読めるコードを書かせるハマった点 - 拡張メソッド - 変に依存が増えて全体像が追いづらくなるため使用を避ける public static class EnemyExtensions
{ public static bool IsThreatening(this Enemy enemy, Player player) { return enemy.IsAlive && enemy.DistanceTo(player) < 5f; } }

読めるコードを書かせる禁止する方法書かれたらコンパイルエラーで落とす

読めるコードを書かせる禁止する方法書かれたらコンパイルエラーで落とす ASTを弄って落とすようにする基本文法は問題なく読めたのでASTも問題なく読めると判断

読めるコードを書かせる LINQ 結果を必ず返すようにする (他にも条件があるものの)とりあえずこの3つが分かれば良い代入、戻り値の部分か？メソッドが LINQ のものか？
戻り値が遅延型か？

読めるコードを書かせる 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);

読めるコードを書かせる 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";

読めるコードを書かせる遅延型かどうか 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";

読めるコードを書かせる禁止する方法書かれたらコンパイルエラーで落とす ASTを弄って落とすようにする基本文法は問題なく読めたのでASTも問題なく読めると判断 →条件式の塊なので全然読める

振る舞いの検証動作が正しいか検証する必要もある実際にプレイするのもありだけど正直限界もあるので自動テストも入れるでもどこまで検証すればいい？

振る舞いの検証こうあってほしいと言うストーリー像があるユーザーストーリーを立ててそれを元にテストを組み立てる BDDを採用

振る舞いの検証 BDD(振る舞い駆動開発) システムの振る舞いを中心に捉える手法 Gherkin記法を使うことで自然言語を元にテストを組むことができる

振る舞いの検証例：プレイヤーがどれだけ粘るかストーリー：生き残った時間でスコアが増える Given:ラウンドが始まったとき、スコアは 0 When:時間が経つ Then:スコアが増える

振る舞いの検証ストーリー通り組めるのでわかりやすい public void GrowsWithSurvivedTime() { // Given ラウンドが始まり、スコアは 0
Score score = new Score(); // When 2 秒生き残る score.Advance(2f); // Then スコアは 1 秒あたり 10 ずつ増え、20 になる Assert.AreEqual(20, score.Value); }

結果自分の想定通りのコードになるので読みやすくはなった。理解が追いつかない部分も機械的に落とすようになっているので、認知負荷の軽減には繋がっている。

結果また敢えて禁止したものがどういった課題を解決するのかを認識できた。なので結果的にC#学習の補助になった。 ※以前はLINQ自体を禁止してたけど徐々にわかってきたので部分的に解放してる

課題 Unity周りの認知負債がたまりやすい - Unityの属性 MonoBehaviour シーンの入れ替え... Unity側を薄くして振る舞い見てるけど、Unityが丸々負債と化すのでこの辺もどうにかしたいところ...

まとめ - 読みづらいものはASTで縛ろう検証に困ったら振る舞いに注目してみる

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

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

マグロ隊長kinTV

More Decks by マグロ隊長kinTV

Other Decks in Technology

Featured

Transcript