💪 Add post

Author: thara

posts/2025-04-28-trying-cline.md

@@ -0,0 +1,90 @@
+---
+title: Clineを試してわかったこと
+date: '2025-04-28'
+published: '2025-04-28'
+---
+
+無職期間という時間的余白を活かして、ClineのMemory Bank機能を試してみたので、現時点での感想をまとめておく。   
+そこで見えたのは、SNSで騒がれているような変革ではなく、現実的で地道なソフトウェア開発の延長だった。
+
+試す前から、生成AIに対して過剰な期待は持っていなかった。
+むしろ、どこまで既存の開発プロセスに影響を与えうるか、現実的な視点で見極めたいという意図があった。
+ClineのMemory Bank機能は単なるプロンプト改善以上に「知識を構造化してエージェントに与える」という思想を持っている点が興味深かったので、実際に試してみることにした。
+
+## 試してわかったこと
+
+世間を騒がしている、いわゆるAIコーディングに対して、自分に見えていない何かがあるのかもしれないと思い、淡い期待を抱いていた。   
+が、それは実践の中で粉砕された。  
+
+プロトタイピングに役立つ場面もあったが、結局は「難しいことは難しい」という当たり前の事実を再確認することになった。
+
+最初は、プロトタイピング用途では一定の効果を感じた。
+特に、新しいライブラリやフレームワークを試すとき、基礎的なコードを素早く出力させるには便利だった。
+学習コストを抑えつつ、動くものを手に入れることができるのは大きな利点だと感じた。
+
+しかし、少し複雑な領域――たとえばオーディオフォーマットの変換や、座標系の扱い、インタラクティブなUI設計――に踏み込むと、途端に破綻した。
+エージェントが生成するコードは断片的で、意図と仕様をきちんと捉えていないことが多く、結局手作業で修正するか、最初から書き直す羽目になった。
+
+また、Memory Bankの整備作業についても、想定していたより "業務感" が強かった。
+これはいわば、プロジェクト憲章やADR（Architecture Decision Record）を書く作業に似ており、結局は「目的を定義し、方針を整理し、それを明文化する」という、自分が前職でソフトウェアアーキテクトとして担ってきた仕事と何も変わらない。
+
+プライベートでさえ、細かいマネジメントに追われる感覚が強く、正直なところ「面白い」とは言い難かった。
+
+
+## SNSでの過剰な期待
+
+SNSでは「AIエージェントが開発を変える」といった熱狂が飛び交っている。
+しかし実感としては、それはソフトウェア開発の根本構造を変えるには至っておらず、単なる効率化ツールの域を出ない。
+
+確かに、労働集約的なコーディング作業、たとえばCRUDアプリのひな形作成や繰り返しの多いスクリプト生成/パフォーマンスチューニング、といった領域では効果を発揮する。
+だが、それはあくまで「作業効率の改善」であって、ソフトウェア開発そのものの根本的な構造が変わったわけではない。
+
+本質的に重要なのは、プロダクトやシステムを設計・運用する上で、目的、設計意図、スコープ、選択理由といった背景情報を適切に整理し、文脈（Context）を維持することだと思う。
+
+ClineのMemory Bank機能は、この「Contextを管理する」という目的のための一つの手段だった。
+エージェントに適切な推論をさせるためには、背景情報を正しく構造化して提供することが不可欠だった。
+
+そして、ここで改めて気づかされたのは、人間同士でソフトウェア開発を行う場合でも、同様に背景情報を整理し、文書化して共有することの重要性は変わらないということだった。
+
+実際、持続可能なソフトウェア開発を志向する組織では、自然にプロジェクト憲章や技術文書、メタ文書（設計意図や方針、判断理由を記録する文書）が整備されている（はず）。
+これらは、AI時代になったからといって突然求められたわけではなく、もともと当たり前に大切だったもの。
+
+今回、Clineを通じて改めてこの点を再発見できたことは、大きな収穫だった。
+
+
+## 生成AI時代の信頼性設計
+
+AIエージェントが開発現場に入り込むにつれて、ソフトウェアの信頼性設計は今まで以上に重要になると感じている。
+
+これまでは、サービス運用やインフラ領域において、SRE的な信頼性設計が重視されてきた。
+しかし今後は、ソフトウェアの品質保証に対する新たなアプローチが求められるようになるかもしれない。
+
+特に、LLMベースのコード生成は便利ではあるが、その生成結果が常に意図通りに動作する保証はない。
+また、ソフトウェア自体にAIエージェントが組み込まれることで、予測不可能な振る舞いをする可能性がある。
+この不確実性を前提にした上で、信頼性設計をソフトウェア全体に組み込んでいく発想が求められる。
+
+例えば、保証すべき信頼性のレベルに応じて、レイヤーごとに異なるアプローチでソフトウェアを構成する、という設計が考えられる。
+
+- 高信頼性が求められる領域
+    - スペシャリストによるマニュアルコーディング
+    - 手厚いQAプロセス
+    - 定理証明支援系ツール
+- それ以外のスピードを優先する領域
+    - LLMによる自動コーディング
+    - AIエージェントによるA/Bテスト(提案)と障害発生時の自動ロールバック
+
+このような状況下では、信頼性工学などの従来の工学手法にも立ち返る必要も出てくるかもしれない。
+
+
+## まとめ
+
+Clineを使った今回の取り組みを通じて、生成AIエージェントが開発プロセスに与える影響について、具体的な実感を得ることができた。
+
+現状では、ソフトウェア開発そのものの構造を変えるような革命的変化は見えていない。
+むしろ、プロトタイピング支援や作業効率化といった「地道な延長線上」で、使いどころを見極めながら付き合っていくべきものだと感じている。
+
+一方で、ClineのMemory Bank運用を通じて、文書化によってContextを整理し”意図”を明確にすることの重要性は、これから先も変わらず求められるだろうという感触を得た。
+
+また、AI時代における信頼性設計については、従来のSRE的な枠組みに留まらず、ソフトウェア設計・実装・運用のすべてにわたって、
+より広範に、より根本的に組み込んでいく必要を強く実感した。
+