youtube版(スライド付き) 関連リンク Fable時代のAI活用法を、Anthropicの開発者が公開本書は、Claude Codeの開発者Thariq氏による、高度なAIエージェント（Fableクラス）を使いこなすための実践的なガイドです。AIの賢さが増した今、ボトルネックとなるのはモデルの性能ではなく「人間側の指示の品質」です。本質的な課題は「地図（人間の指示）は現地（コードベースや現実の制約）ではない」という認識の乖離にあります。このギャップ（未知）を最小化し、AIの推測による失敗を防ぐために、以下の4段階で問題を分解・整理することが重要です。未知の分類: 指示を「既知の既知」「既知の未知」「未知の既知（見れば判断できる）」「未知の未知（自分でも気づいていない制約）」の4つに分類します。実装前のアプローチ: AIに自身の盲点を探させる「ブラインドスポット・パス」や、プロトタイプを用いた意見交換、具体的なソースコードをリファレンスとして渡すことで、早期に認識のズレを解消します。実装中のログ: 計画からの逸脱を「Deviations」として記録し、柔軟に軌道修正を行います。実装後の検証: レビュー準備として説明資料をまとめ、最終的にAIに自身の内容をクイズ形式で出題させることで、理解の確実性を担保します。 AIが賢い時代だからこそ、小手先のテクニックではなく、コードベースやドメイン知識を深く理解し、AIと対話的に「未知」を減らしていくスキルがエンジニアには求められます。記事ではこれらのテクニックをまとめた「SKILL.md」形式のガイドも公開されており、日々の開発に即座に取り入れることが可能です。引用元: https://zenn.dev/knowledgesense/articles/283244af941a2d AIコーディング時代の生き抜き方生成AIの普及により、コーディングの生産性は飛躍的に向上しました。新人エンジニアがこの環境下で価値を発揮し続けるためには、単なる「コードを書く量」ではなく、以下の3つの視点が重要となります。「何をつくらないか」を見極める AIによって機能を実装するコストは下がりましたが、それ以上に「その機能が本当にプロダクトの価値に繋がるのか」という判断が重要になります。機能を量産するだけの「Feature Factory」に陥らず、プロダクトの本質的価値に向き合う時間を大切にしてください。自分の軸を持つ（広さより深さ） AIの進化で、エンジニアがデザインや企画（PM）の領域に踏み込むことが容易になりました。しかし、いたずらに全方位の能力を広げようとすると、器用貧乏になりかねません。何でも屋を目指すのではなく、自分の中の専門的な「軸」を明確に持った上で、周辺領域へ知識を広げていく姿勢が求められます。アジャイルの本質を強化する開発速度が上がることで、従来以上に短いサイクルでフィードバックを得ることが可能になりました。機能開発そのものにかかる時間が減った分、リリース後の検証体制の整備や、ステークホルダーとの対話など、プロダクトの価値を最大化するためのプロセス改善に労力を割くべきです。結論として、AIは強力なツールですが、向かうべき方向や課題の選定といった「判断」は人間に残された重要な責務です。技術の変化に焦りすぎず、開発の本質的なプロセスや自身の専門性を磨き続けることが、この時代を生き抜くエンジニアのキャリア形成につながります。引用元: https://zenn.dev/garasubo/articles/9b9548ebab5a67 デザイナーの脳内をコピーして、誰でも90点以上のUIを作れるようにする本書は、AIエージェント（Claude Code）を活用し、デザイナー不在のチームでも高品質なUIを継続的に作成・実装するための仕組みづくりに関する事例です。背景と目的: 開発チームの急拡大によりデザイナーが不足する中、品質のバラつきを抑えつつ、エンジニアやPMが自律的にデザインを完結させる環境を目指しました。デザイナーの判断基準をシステムに組み込むことで、レビューのみに注力できる状態を作るのが狙いです。仕組みの概要: 2つのリポジトリ（デザインの正となるnewt-design-systemと、作業用のnewt-spec）を構築しました。デザインシステム: UIコンポーネントだけでなく、UXガイドラインや命名規則を機械可読な形で管理。design-system MCPを通じて、Claude Codeが常に最新の判断基準を参照できる環境を整えています。ワークフロー: design-builderスキルを導入し、デザイナーが思考する「調査→案出し→仕様決定→実装への接続」というフローをAIに再現させています。エンジニア向けのポイント: シングルソース: UIの実装とデザイン案が同じコンポーネントをimportすることで、作り直しゼロの引き渡しを実現しています。判断基準の明文化: 11種類のルールファイルをAIの判断ロジックとして用意し、設計思想を再現可能なものにしました。 MCPの活用: 社内共通MCP環境を利用し、各チームがセットアップ不要でデザインソースへアクセスできるようにしています。結論として、デザインシステムを「人間向けのガイドライン」から「AIの判断エンジン」へと進化させることで、デザイナーの知見を全チームにレバレッジさせる取り組みです。引用元: https://note.com/toitoi1618/n/ndf35dbd2585b 謝って済むことを頑張って予防しないシステム運用における再発防止策は「やって当たり前」と思われがちですが、実際には必ずコストが発生します。工数やリソースは有限であり、過剰な対策は本質的な開発の余力を削ぐことになります。新人エンジニアの皆さんも、トラブル後の振り返りでは「対策のコスト」と「再発時の損失」を天秤にかけましょう。「謝って済むことはあえて予防しない」という選択肢を冷静に検討することが、健全な開発・運用の第一歩です。引用元: https://blog.pinkumohikan.com/entry/option-to-not-improve お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）

Ask this episode

“What did the council decide on item 42?” — answered with the speaker and the moment.

Transcript

Related