リーナー見積チームの井上です！
本記事ではリーナーの開発チームで最近話題になっていることをお届けします。
AIエージェントのシステムプロンプトが面白い
AIエージェントのシステムプロンプトをCursorに語らせてみた以下の記事が話題になっていました。
記事内で印象的だったのは、AIエージェントは「最初から宗教を持っている存在」で、その宗教にあたるのがシステムプロンプトであるという表現。 Cursorにシステムプロンプトを語らせてみたら「美しくなくても動けばヨシ！」的な思想だったとのことで、「なんとなくそんな気はしていたけど結構ショッキング」という声が上がっていました。
じゃあClaude Codeはどうなの？ということで、「自分のシステムプロンプトと反対の指示を書いて」と聞いてみたところ、「将来の拡張性と設計の美しさを優先する」「関連する全てのコードを積極的にリファクタリングする」等が出てきました。つまりClaude Codeは「動く実装優先」「頼まれたところだけ直す」が基本方針と考えられます。
エージェントが言うこと聞いてくれないなーと思ったとき、システムプロンプトが影響している可能性がある、というのは覚えておくとよさそうです。チーム内でのルールや基準をドキュメントとして明記することが結局必要そうですね。
by リーナー見積チーム おぐさん(@hogucc)
レビューコメントの温度感、みんなどうしてる？
チーム内でレビューコメントの温度感の話が盛り上がったので、全社のエンジニアでレビュー観点について議論をしました。
議論のきっかけになったチーム内では、NITS や IMO などの意図が伝わらない表現は使わず、「要対応」か「対応不要」を使うようにルールを制定しました。
全社のエンジニアでの議論ではレビューコメントについてだけでなく、レビューで何を保証したいのか・AIがコードを書くようになったことでのPRレビューのあり方、などより広い観点で意見を出し合いました。 きっかけにあったとおりNITS・IMOの解釈が人によってバラバラだったり、「AIレビューのほうがいい指摘くれる」「いやドメイン知識ベースの判断は人間じゃないと」だったり、いろんな考え方が出てきました。「コード品質の基準は機械的じゃないと水掛け論になりやすい」という話から、カスタムCopをClaude Codeに書かせたら良い感じだったという実践例もありました。
AIレビューの活用度合いもチームによって結構違っていて、Devin Reviewの結果をざっと見てapproveする人もいれば、ClaudeとCodexでクロスレビューを必須にしているチームもありました。
共通方針を決めるには至らなかったですが、色々な観点での話が聞けてよかったです。
by リーナーコネクトチーム 黒曜さん(@kokuyouwind)
Amazon Bedrock で Palmyra Vision 7B が使えるようになった
AWSの発表で、Writerの Palmyra Vision 7B が Amazon Bedrock で使えるようになりました。
画像理解・手書き文字の抽出・チャートの解釈が得意なマルチモーダルモデルで、文書に含まれるチャートや画像もまとめてテキスト化できるとのこと。各プロダクトで色々な種類のファイルをやりとりしているので、何か活用方法があるかも？という話が出ていました。
by 新規事業チーム luluさん(@lulu_lul2)
宣伝！
気になる話題があれば、ぜひリーナーの開発者たちと話しましょう！
