youtube版(スライド付き) 関連リンク Opus 5では今までのプロンプトが逆効果に。「検証して」を消して「簡潔に」と書くべし。公式プロンプトガイドを読み解く Claude Opus 5の公式プロンプティングガイドが公開され、従来のモデル向けノウハウが逆効果になるポイントが明らかになりました。新人エンジニアが実務でClaudeを活用する際、特に押さえるべき要点は「簡潔さの指示の追加」と「検証指示の削除」の2点です。まず、Opus 5はデフォルトで応答が長くなる傾向があり、エフォートパラメータ（effort）を下げても文章量は短くなりません。そのため、CLAUDE.mdなどのシステムプロンプトに「焦点を絞り、手短かつ簡潔に。高レベルの要約を返すこと」といった簡潔さの指示を基本セットとして明記する必要があります。次に、旧モデルで品質担保のために慣習的に使われていた「検証して」「再確認して」「ダブルチェックして」といった指示は、Opus 5では削除が推奨されます。Opus 5は自ら作業を検証するため、これらの指示を残すと過剰検証となり、無駄なトークン消費やコスト増につながります。また、サブエージェントも積極的に使いすぎる傾向があるため、独立した大きなタスクに限るよう制御する指示が必要です。思考（Thinking）機能はデフォルトでオンのまま使い、effortは「high」から始めてタスクに応じて調整します。コーディングなどの難易度が高いタスクでは、TODOなどを残さず完全に完了させる高い能力を発揮します。このように、新モデルではプロンプトを「足す」のではなく「削る」方向への頭の切り替えが求められます。旧モデル向けの細かい手順書や検証指示は見直しを行い、モデルの進化に合わせた適切なプロンプトチューニングを行いましょう。引用元: https://zenn.dev/little_hand_s/articles/72646a09f49d2a Hermes Agent と Slack で設計し、Linear のチケットから Draft PR まで作成するワークフローの素振りをした AIエージェントによる開発の主流がローカルCLIからリモート環境へ移行する中、オープンソースの「Hermes Agent」を使い、SlackとLinearを連携させた自律的開発ワークフローの構築手順が解説されています。本ワークフローでは、役割ごとに2つのエージェントを使い分けます。 Planner Hermes: Slack経由でユーザーの要件を聞き出し、対話形式で仕様を詰める設計用エージェント。grill-with-docs、to-spec、to-ticketsなどのスキルを使用し、合意形成後にLinearへチケットを自動登録する。 Coding Worker: チケットの登録を契機に、cronジョブで定期的にタスクを検知して実装を担当する使い捨てエージェント。テストや型チェック、リントが成功した段階でGitHub上にDraft PRを作成し、Slackへ通知する。運用上のポイントとして、エージェントのプロファイル作成機能を活用し、利用可能なツールやファイルアクセス権限を最小限に絞り込むことが推奨されています。また、ConoHa VPSなどのクラウド環境にHermes Agentのゲートウェイを常時稼働させることで、ローカルPCを閉じてもモバイル端末やSlackからいつでも指示を出せる開発体制が実現できる内容となっています。引用元: https://azukiazusa.dev/blog/hermes-agent-slack-workflow Bringing PyTorch Monarch to AMD GPUs: Single-Controller Distributed Training on ROCm – PyTorch 大規模言語モデル（LLM）の分散学習では、数百〜数千規模のGPUを用いるためハードウェア障害は不可避です。従来は定期的なチェックポイント保存とジョブ全体の再起動が主流でしたが、I/O負荷やアイドル時間によるリソースの無駄が生じていました。これに対しMetaなどは、AMD Instinct GPUとROCm環境へ「PyTorch Monarch」を移植し、単一コントローラによる弾力的かつ耐障害性に優れた分散学習を実現しました。 Monarchのアーキテクチャは、Python API、Actorベースのランタイム、Rust（Tokio）による高速かつ安全な処理基盤から構成されます。CUDA環境向けに設計されていたMonarchをROCmに移植するため、hipify_torchを活用したC++コードのHIP変換やRCCLのリンク、GPUメモリ管理やRDMA（libibverbs）のHIPバインディングへの適応が行われました。特にRust側では、直接的な静的リンクが存在しない動的リンクの課題に対し、互換性モジュール（rocm_compat）を導入してCUDA由来の関数名をHIPにマッピングし、Rust側のコードをプラットフォーム非依存に保つ工夫がなされています。耐障害性の仕組みとしては、Monarchのスーパービジョンツリーによるプロセス監視と、訓練エンジン「TorchTitan」、障害耐性モジュール「TorchFT」が連携します。プロセス障害発生時は、被災したレプリカのみが局所的に再起動し、健全な他のレプリカは訓練を継続します。復旧時にはLighthouseを介して生存中のレプリカからピアチェックポイント転送が行われ、グローバルな全体再起動なしに最小限のオーバヘッドで同期・復帰します。 SLURM環境の16ノード（128基のMI300 GPU）や、Kubernetes環境の32ノード（256基のMI355 GPU）を用いた検証では、意図的な障害を頻繁に注入しつつも、全体の損失関数はスムーズに収束し、大規模AMD GPU環境での高い実用性と安定性が実証されました。今後はネットワーク（NIC）サポートの拡張やRLフレームワークへの対応、復旧レイテンシのさらなる削減が予定されています。引用元: https://pytorch.org/blog/bringing-pytorch-monarch-to-amd-gpus-single-controller-distributed-training-on-rocm/ お便り投稿フォーム VOICEVOX:春日部つむぎ

Ask this episode

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

Transcript

Related