みなさん、こんにちは！マイクです！今日は2025年8月8日、曜日は金曜日です。さて、今日の「zenncast」では、Zennでトレンドの記事をいくつかご紹介していきますよー！
それでは、さっそく今日の内容に入っていきましょう！
今日紹介する記事は全部で5本です！まず最初の記事からいきましょう。
1つ目の記事は「AIでテキストファイルを書き換える技術」です。この記事では、AIを活用したテクニカルライティングの効率化プロジェクトについて詳しく説明しています。特に、従来のテキスト生成手法の問題点を指摘し、「差分ベースの編集」という手法を用いることで、元のテキストを尊重しながら最小限の変更を行う方法が紹介されています。
具体的には、オープンソースのAIエージェントであるAiderとClineのプロンプト実装を参考にし、SEARCH/REPLACEブロック形式を採用しています。この形式では、変更前後の文脈を含めることで、AIが行番号に依存せずに正確な差分を適用できる仕組みがあります。また、出力形式のプロンプトにおいても、変更が必要な場合には具体的な検索/置換ブロックを提供することが求められています。
実際の実装例として、Amazon Bedrockを使用したAIエージェントに対してYAMLファイルの特定の設定を変更するプロンプトを与え、AIが正しくファイルを更新する様子も示されています。サンプルコードでは、AIからのレスポンスをもとに元の内容を変更する手順や、検索/置換ブロックの解析方法が詳述されています。
最後に、AIエージェントの利用方法を理解し、独自のエージェントを作成することで、より柔軟なAIの応用が可能になることが強調されています。AIを単に利用するのではなく、その実装方法を学ぶことが、エンジニアにとっての新たな可能性を開くことが述べられています。
。...。...。...。
次に紹介するのは「『AI駆動経営』Claude Codeを用いたバイブコーディング開発フロー」です！株式会社エムニでは「AI駆動経営」プロジェクトを進めており、社内業務の効率化を目指しています。この中で、LLMチャットクライアントをClaude Codeを用いて開発し、特に社内ドキュメントを活用したRAG（Retrieval-Augmented Generation）の基盤を構築しています。
開発するアプリはAzure AI Foundryを利用したチャットボットで、バックエンドはPython、フロントエンドはNext.jsです。まず、Gemini CLIを用いてWeb検索を行うための設定を行い、次にプロンプトを使ってアプリの設計を進めます。設計段階では、システムアーキテクチャやバックエンド・フロントエンド設計、Azure統合、通信設計、セキュリティ、デプロイメント戦略などのドキュメントが生成されます。
実装にあたっては、環境変数を設定し、Claude Codeによりベースラインの実装を進めます。設計が適切であれば、実装も円滑に進むため、設計に注力することが重要です。また、CLAUDE.mdに開発ガイドラインやテスト駆動開発(TDD)の戦略をまとめ、重要な指示を記録します。
さらに、GitHubでのIssueベースの開発フローを確立し、チケットに基づいて実装を進めます。各ステップでテストを実行し、PRを作成する流れが確立されています。エムニでは、生成AIを活用したアプリケーション開発に興味があるエンジニアを募集しており、最新技術に触れながら自らのアイデアを形にできる環境を提供しています。興味のある方はカジュアル面談にお声がけください。
。...。...。...。
続いて紹介するのは「アニメーションのフレームをテストしない。その理由を解説します。」です！アニメーションのテストを1フレームずつ行うのは非現実的であり、主な理由として「タイミングの不確実性」「環境の非一貫性」「保守性の問題」「膨大なデータとリソースの問題」が挙げられます。
例えば、`setTimeout`によるテストは、実行タイミングが環境に依存し、成功や失敗が不安定になります。また、ローカルマシンとCI/CD環境の性能の違いや、ブラウザ間の差異も問題を引き起こします。
さらに、アニメーションのCSSが変更されると、テストコードを再計算・更新する必要が生じ、保守が困難になります。フレーム単位のテストを行うと、生成されるデータ量が膨大になり、実行時間やストレージに負担がかかり、実用的ではありません。
代わりに、アニメーションのテストは「結果」と「体験」に焦点を当てることが求められます。具体的には、初期状態と最終状態を確認する正当性のテスト、見た目の変更を捉えるための視覚回帰テスト、パフォーマンスを評価するための滑らかさのテストが有効であると説明されています。これにより、ユーザーにとって意味のある体験を保証するテストを実現できるのです。
このアプローチは、フレーム単位のテストに伴う負担を軽減しつつ、実用的でメンテナンス可能なテスト戦略を提供します。
。...。...。...。
次にご紹介するのは「Gemini Canvasでも大体のGASはかけるよーという話」です！本記事では、筆者が「Apple Business ManagerのAPIを使い、Notion DBに端末一覧を作成するGASツール」をGemini Canvasを用いて開発した過程を解説しています。
Gemini Canvasを使用することで、コードの生成と修正が容易になり、エンジニアの作業負担が軽減されます。基本的な流れは、Canvasで生成したコードをGoogle Apps Scriptのスクリプトエディタに貼り付け、必要に応じて手動で修正を加えるというものです。
プロンプトを工夫することで、初めから全ての機能を実装するのではなく、段階的に完成形に近づけることができます。さらに、GASをコンテナバインドスクリプトとして設定し、スクリプトプロパティを利用してアクセストークンを安全に管理する方法も説明されています。
APIリクエストに関する細かな設定やエラー処理についても言及されており、誤字があってもAIは柔軟に解釈してくれる点が強調されています。最終的には、Googleスプレッドシートにデバイス情報を書き込み、Notionに同期する機能を備えたGASの完成品が紹介されています。
Gemini Canvasを利用することで、GASの開発がより身近で容易になることを筆者は実感しており、過去の経験を踏まえた上で、このツールの有用性を強く推奨しています。GASに挑戦したことがないエンジニアにも、是非試してみる価値があると述べています。
。...。...。...。
最後に紹介するのは「CursorとNotion MCPを活用した『AI伴走型テスト設計』の実践プロセスと、その学び」です！グロービスの池邊氏が、CursorとNotionを用いてAIと協調したテスト設計プロセスの実験を行いました。実験の目的は、AIとの協業によりテスト設計プロセスを変革する可能性を探ることです。
具体的には、テスト対象分析からテストケース実装までの全5ステップをAIに伴走させています。まず、Cursorを使ってNotionの仕様書を読み込み、AIにテスト対象を理解させることで質の高い分析を実現しました。次に、テスト要求分析ではAIに質問させ、思考を深めて計画の骨子を固めました。
テスト設計と観点出しでは、AIの提案をもとに人間が最終判断を行い、質の高いテスト設計ができました。最終的に77件のテストケースを約2時間で生成したそうです。
実験から得られた学びとして、AIは思考の整理や共同作業において価値があることが示されました。また、プロセスの可視化や標準化が可能で、属人化を防ぐ効果も期待できるとされています。反省点として、AIが生成したテストケースが過剰になる可能性や、効率の評価、レビュープロセスのボトルネックが挙げられました。
結論として、AIはテストプロセスの有力なパートナーになり得るが、効果的に活用するためには人間の技術と経験が必要であることが強調されています。AIを運転席のナビゲーターとして使いこなすことが、今後の課題です。
さて、今日は紹介した5本の記事を駆け足でおさらいしてみました！次回またお会いできるのを楽しみにしていますよー！詳しい内容はショーノートに書いてありますので、ぜひチェックしてくださいね！それでは、番組の感想もお待ちしています！ありがとうございました！