仕事をしていると、だんだんと抽象度の高いことを任されるようになる。 たとえば、方針も明確な小さな修正タスク => 修正方法がいくつか考えられるタスク => そもそも何をやるかから明確にしないといけないタスク といった感じで次第にふわっとした依頼になってくる。いわゆるグレード制を採用している会社において、"どれだけ抽象度の高い仕事を任せられるか" がグレードの違いの要素のひとつと言ってもいい。 抽象度の高い仕事を安心して任せられる人は何が違うのか自分もよくわからないので、自分のまわりの人がどういう動きをしているかを雑にまとめてみる。 1. なぜやるかを明確にしている わからないときはドキュメントやチャットのやりとりを探し、直接聞いたほうがよい人には自分でコミュニケーションを取っている やる理由がないと判断したら依頼者に話をして、実際にやらないこともある あとで「自分はこう言われただけなので」

ITエンジニアがLLMベースの生成AIを使いこなせるようになることを目指した本です。 まずはLLMの仕組みの理解してメンタルモデルを構築し、次に代表的なプロンプトエンジニアリング手法を学ぶことで基礎を固めます。 最後に、ITエンジニアならではのプロンプトテクニックを紹介しますので、応用力を身につけましょう。

こんにちは、LegalOn Technologiesで検索エンジニアをしている志水(@banbiossa)です。 食事つきの勉強会を開催する際に、学び目的ではなく飲食目的、いわゆる「タダ飯狙い」の方に遭遇したという声を最近多く聞きます。 この「タダ飯狙い」や不審者の対策にむけて、リーガルテック企業ならではの取り組みとして、参加規約のひな形を準備しました。 本記事では、取り組むまでに至った経緯や過程、ひな形の詳細、協力してくれた方々についてご紹介できればと思います。 勉強会の治安の悪化 弁護士ドットコム社の記事 検索技術勉強会における実体験 勉強会用・参加規約のひな形 ひな形本文 ひな形とは？ 活用方法について ひな形の活用 勉強会の運営 勉強会用・参加規約ひな形プロジェクトの全容 シャッフルランチでCTOに投げかける 法務・法務開発の巻き込み ドラフト→レビュー→公開 ひな形作成時の想定

RAGの精度改善するために何があるかを学びました。基本系のNaive RAGを知っている人向けの記事です。 方法が多すぎるので、Youtubeの「RAG From Scratch」を中心に少し整理してみました。LangChainをよく使っているので、LangChain出典が多いです。 全体像 まずは、RAGの全体像。Indexingが同じ流れにあるのが少しわかりにくいのですが、実行タイミングとしてはRAGの前準備としてやっておきます。 画像出典: RAG from scratch: Overview もう少し粒度を細かくした図です。 画像出典: RAG from scratch: Overview 表形式で分類します。Generationだけ少し特殊です。 大分類 中分類 内容

サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。 このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。 そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。 納得できないケースは大まかにどのようなものがあるか 納得できないケースでは大まかに2つのケースがあるのかなと思っている。 (1) 施策をしたい目的や仮説自体に納得できていない (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない 1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか？」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか？」「この指標に繋がると言っているが

フォント逆引き辞典 デザイナーがおすすめするモリサワフォント100選！「定番」「楽しい」「力強い」etc... といったキーワードから用途別に調べられるフォントの逆引き辞典。書体の特徴を活かした作例の見本付きで、書体の特長やポイントを丁寧な解説します。記事は随時更新。

ついにGenAI on AWSの日本語版が！ IT技術書で有名なオライリー社より、新刊「AWSではじめる生成AI」が来週8/2に出版されます。すでに予約可能。 AWSではじめる生成AI Chris Fregly、Antje Barth、Shelbee Eigenbrode　著、久富木 隆一　訳、本橋 和貴、久保 隆宏　技術監修 これは昨年11月に刊行された同社の洋書「Generative AI on AWS」の日本語版となります。 原著はAWSの米国拠点で生成AIを担当する3名のエキスパートによる書籍です。AntjeさんはAmazon Bedrock関連のAWS Blogでもよくお見かけしますね。 今回、日本語訳にあたって技術監修をご担当されたAWS Japanの本橋さんと久保さんより、ありがたいことに発売前の献本（ご恵贈）にあずかりましたので、読んだ感想を簡単にアウトプットさせていただき

RAG (Retrieval-Augmented Generation)とは ● 外部データをRetrieval（検索）して ● プロンプトをAugument（拡張）し ● クエリに対する回答をGeneration（生成） ○ クエリ := ユーザからの問合せ ・・・する技術 ※本講義では「インプット＝クエリ＋プロンプト」と定義 4 RAG (Retrieval-Augmented Generation)とは 登場人物＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ビジネスでの応用先はLLMが大多数＿ ❶検索アルゴリズム ● ・ベクトル検索、全文検索、及びその組合せ （Hybrid検索）がよく使用される ・…が、それに限るものではない ● ビジネスでは”言語”の基盤モデル （LLM）への応用が多い ○ 本講義も LLMに注力 一方、言語以外のモーダル （画像・音声等）も研究開発中 ❷拡張処理アルゴリズム ・

はじめに こんにちは、皆さん。今日は、シェルスクリプトを使った高度な自動化のベストプラクティスとパターンについて解説します。これらは、ちょっとした知識で実行でき、作業を大幅に効率化できるTipsです。シェルスクリプトは、特にUNIX系システムでの自動化タスクに欠かせないツールです。適切に使用すれば、複雑なタスクを効率的に、そして信頼性高く実行できます。 トイルとは、反復的でマニュアルな作業のことを指します。これには、例えば、手動でのシステムのスケーリングや、エラーのトラブルシューティング、ルーティンなメンテナンス作業などが含まれます。トイルを特定し、それを自動化することで、エンジニアはより創造的なタスクやプロジェクトに焦点を合わせることができます。 トイルを判別する方法としては、以下のような基準が挙げられます： 手作業であること 完全な手作業だけでなく、「あるタスクを自動化するためのスクリ

はじめに ChatGPTブームがひと段落した感がありますが、周りのエンジニアでChatGPTを活用している姿をあまり見みません。 基本的なテクニックを理解すれば、エンジニアこそChatGPTを活用できると思うので、普段使用しているテクニックをいくつかピックアップして紹介します。 プロンプトの記載方法 Markdown記法で指示する 色々なところで紹介されていますが、回答や処理の精度を上げる方法としてChatGPTへの指示にMarkdown記法を使用することがオススメされています。 例えば下記のような文章による指示を行おうとした場合

ソフトウェアエンジニアは、どのように事業に貢献すべきか？ 宿泊施設やレストランの予約サービスを提供する株式会社一休で執行役員CTOを務める伊藤直也さんは、2016年に入社しておよそ2年間、心の奥に抱えた悩みを解消できないまま仕事をしてきました。 伊藤さんは、2000年代から複数のWeb系テックカンパニーで技術部門のリーダーとして活躍し、現在でも利用される個人向けWebサービスのローンチをいくつか手掛けています。一休には入社以前からフリーランスで技術顧問を務めており、会社がヤフーグループ（当時）に入って経営陣が一新されるタイミングで、代表取締役CEOとなった榊淳さんの要請を受けて入社しました。 当時は全て.NETだったというサービス基盤の刷新や技術的負債の解消、開発組織の整備といったエンジニアリングにおいて重要な改善を進めてきましたが、あるとき自身が「事業に貢献していない」ことを明確に意識す

こんにちは、AWS事業本部の荒平(@0Air)です。 AWS Summit Japan 2024にて、AWS-TC-04「プロンプトエンジニアリング入門」のセッションに参加しましたのでレポートします。 オンデマンド配信を見よう AWS Summit Japanの登録を行うことでオンデマンドで視聴可能です。（現地参加された方は改めての登録は不要です。） "AWS-TC-04"を検索してみてください。 セッション概要 このセッションでは、基盤モデルの基本とプロンプトエンジニアリングの主要な概念について学びます。 また、プロンプトを設計するためのベストプラクティスと、ゼロショット、フィューショット、 Chain of Thought プロンプティングなどのいくつかのプロンプティング手法について、例を通して学びます。 セッションスピーカー： 佐中 晋 氏 所属：アマゾン ウェブ サービス ジャパン

こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab

最近、分散データベースとかNewSQLとかサーバレスなデータベースとか色々聞きますよね。 でも、専門ではない人たちにとって、「何が違うの？」「自分たちに必要なDBはどれなの？」という点が分かりづらいと思います。 私も良く聞かれます。 AuroraはNewSQLですか？ NewSQLってサーバレスなんですか？ スケールできないDBとか聞きますけど、リードレプリカ増やせますよね？ などなど。この辺に基本的なところから答えられるように、順を追って解説していきましょう。 「コンピュートとストレージは別であれ」 と神が言うと、コンピュートとストレージは分離された。 と言うのは冗談ですが、まずはここからスタートしましょう。 クラウド以前のデータベースを使っていた人にはお馴染みのように、それまでデータベースは大きな1つの箱でした。 過去に私は下図でデータベース（厳密にはRDBMS）のコンポーネントを解説

OKRと「測りすぎ」 〜なりたい姿を、「測りすぎ」ないようにしながらどう追いかけるか〜/OKR and the tyranny of metrics

1971年東京生まれ。イラストレーター。ドクロ服、ドクロ雑貨集めに情熱を燃やしすぎている。ほかにはワニ、ウツボ、ハダカデバネズミなど毛の生えていない動物も好む。著書に「しろねこくん」、「ココロミくん」、「ひとみしり道」、「ばかスイーツ」などがある。（動画インタビュー） 前の記事：チーズには動詞がつきがち

多くの研究者や医療従事者にとって、抄読会は情報収集と知識共有の重要な機会ですが、スライド作成には多くの時間と労力を費やしてしまいがちです。そこで、このプロセスを自動化するプロンプトを作成しました。 使い方は簡単です。論文のPDFを添付し、プロンプトを入力するだけで、AIがその論文の要点をまとめたスライドの下書きを自動で生成してくれます。背景、方法、結果、考察、結論の各セクションごとにスライドが作成され、重要な情報が簡潔にまとめられます。 ただし、このプロンプトを最大限活用するには、抄読会で取り上げるべき適切な論文を選ぶことが大切です。抄読会で選ぶべき論文のルールがある場合はそれをよく確認し、他の先生の貴重な時間を使って行うものなので、なるべく価値のある論文を選ぶようにしましょう。自信がない場合には選択が合っているか上級医に確認しましょう。具体的には、以下のような基準を満たす論文がおすすめで

エンジニアの岡村です。 自分はサーバーがメインではなく、あまり業務でガッツリ触るわけでもないのですが、最近それなりに活用するようになってきました。しかし、ネット上の日本語情報を読んでいるだけではこれの書き方が正しいのかよく分からない、と悩むことが結構あったため、色々情報を漁ってみました。 この記事は、特に自分が気になった部分の調べた結果を記事に纏めてみたものです。対象読者はdocker-composeを雰囲気でupやdownは叩けるけどComposeファイルの書き方がよく分からんとなってる人です。 Docker Composeの概要とcompose.yaml、Compose Specの関係 compose.yamlの書き方は Compose Specに準拠すればOK Compose Specの場所 推奨のファイル名はcompose.yaml compose.yaml内にバージョンを記述する

CTO 室の恩田です。 今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。 きっかけ とあるエンジニアが Slack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。 それを見かけた別のエンジニアが技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる？」の一言で、有志が集って評価プロジェクトが始まりました。 雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした（笑）。 この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜