エンジニアミートアップのはじめかた
技術情報のキャッチアップは、業務が忙しくなると最初に削られます。意志の問題ではなく、情報収集が時間を細かく、けれど継続的に消費する活動だからだと思っています。newmoでは立派な仕組みを作るより、忙しい週でも続く軽いものとしてエンジニアミートアップを行なっています。 Engineering Meetup とは newmoには「Engineering Meetup」という場があります。週に一度、エンジニアリングに興味のあるメンバーが話題を持ち寄る1時間のランダムトークです。毎週金曜の夕方に、所属や雇用形態を問わず誰でも参加できます。テーマはWebでもモバイルでもクラウドでも自動運転でも、最近読んで面白かった本でもよく、「newmoのここに困っている」といった仕事の話も歓迎です。 コンセプトは「準備を頑張らずにゆるく話す」。資料は作らず、話したいテーマをNotionに書いて当日集まって話します。参加は強制せず、忙しい週は欠席でも、耳だけのラジオ参加でもよく、最低2人集まれば開きます。 モチベーション 一人で技術の変化を追い続けるのには、限界があります。割ける時間と注意が有限だからです。だったら一人で抱えるより、チーム全員が薄くアンテナを張って持ち寄るほうが、広く拾えます。持ち寄って話すこと自体が、お互いの興味や困りごとを知る機会にもなります。そして拾ったものを読んで終わりにせず、自分たちのコードや仕事へつなげたい。このやり方は、負荷を分担すること、消費で終わらせないこと、お互いを知ることのために続けています。 やっていること エンジニアミートアップをやるには何かしらの話すネタ集めが必要です。 ネタ集めの仕組み自体は目新しくありません。Slackで気になったメッセージ（記事、リリースノート、インシデント、誰かの登壇やブログ）に、専用の絵文字（:meetup_neta:）を押します。するとReacji Channelerが、それをネタ帳チャンネル（#nm-dev-meetup）へ自動で集めてくれます。 engineer-meetup 肝心なのは、投稿し直す手間がないことです。読んでいる場所でスタンプを押すだけなので、忙しい週でも止まりません。 絵文字はあえて1種類にしています。「紹介したい」「聞きたい」と意図で分けたくなりますが、分けると押す前に迷いが生まれ、その一瞬が手を止めます。信号は「気になった」の一点でいい。分類は、後で人が話すときにやれば足ります。 週に一度、溜まったネタをClaude Coworkに渡し、古い順に要約してNotionのmeetupページにまとめさせます。各ネタはSlackやNotionを検索させて背景を補わせます。これがその週のアジェンダになり、あとは毎週の定例でそれを見ながら話します。 Coworkでスケジュール実行しているプロンプトもすごく単純です。 Notionの「Engineering Meetup」の今日のmeetupページにネタを古い順でまとめてください。 * Slackの#nm-dev-meetupから古い順まとめてください * 前回のものを見てサマリの書き方は見てください * サマリに必要な情報はSlackやNotionなどを検索してまとめてください 線の正しさは、点が一定量ないとわからない 集めたネタは、ひとつひとつが点です。その点を並べて「これはこういう流れですね」と解釈する、つまり線を引くのは、そんなに難しくありません。これは人だけでなくAIにもできます。情報を渡せば、AIはもっともらしい線をいくらでも引いてくれます。 問題は、その線(解釈)が当たっているかどうかです。そして線の正しさは、点が一定量ないとわかりません。研究の作法を扱ったリサーチのはじめかたという本に、点が少ないとその点を通る線は何本でも引けてしまう、という話があります。資料が少なければ解釈は無限にある。これは引く主体を問いません。人が引いてもAIが引いても、点が少なかったり偏っていたりすれば、それらしいだけの線(解釈)になります。 点がひとつしかない、あるいはほんの少ししかないときに、どうやって点と点をつなぐことができるだろう。まだほんのとっかかりの段階で、解釈や議論──点と点を結ぶ推論の線──をどうして描きはじめることができるだろう。点がひとつ、ふたつ、あるいは三つしかないとしたらどうだろう。 (...中略...) 研究の初期段階では、問いや解釈の可能性が無数にあるから、点と点を結ぼうとしてもあっという間に収拾がつかなくなる。つまりこのパズルは解けないのだ。これほど「点」の数が少ないと、その点を通る線は何本でも引けてしまう。つまり研究者目線で言えば、資料の数が少ないときは、筋立ても解釈も無限に存在することになる。 -- リサーチのはじめかた - トーマス・S・マラニー、クリストファー・レア そのため必要なのは、全員が薄くアンテナを張って、点をたくさん、いろんな方向から集めることです。点が増えるほど引ける線は絞られ、それらしいだけの線が当たる線になっていきます。 たとえば、この数ヶ月のサプライチェーン攻撃がそうでした。axiosやCheckmarx/Bitwardenの侵害（4月）、TanStackのpostmortem、Nx Console拡張の汚染（5月）、CAMPFIREの不正アクセス調査レポート（6月）。どれも単発で見れば「物騒だね」で流れていく点です。 それが数ヶ月、複数人のアンテナで溜まって初めて、「漏れたトークンがCI/CDを踏み台に本番へ権限昇格していく」という一本の線が見えてきました。1点や2点では、ここまでの線は引けませんでした。 場をひらき続けること いちばん大事だと思っているのは、毎週決まって話す場があることです。ただ、この場の目的は、その場で答えを出すことではありません。持ち寄ったネタを声に出し、お互いのアンテナを重ねて、拾えるネタを増やしていき、コミュニケーションに繋がる。それが場の役割です。 たまに「これ先週のあれと繋がるね」と、その場で点と点がつながることもあります。でもそれは狙って起こすものではなく、点が十分たまったときに、ときどき現れるくらいのものです。毎回つなげようと気負わなくていい。点を持ち寄り続けることのほうが、ずっと大事です。 場そのもの（カレンダーの繰り返し予定とMeetのリンク）を用意するのは簡単です。本当に必要なのは、誰かが口火を切り、参加に濃淡があっても回り続けること。スタンプも顔出しもコストは下げてあるので、回す人さえいれば成立します。 線は誰にでも引けます。けれど、その線が正しいかどうかは、集めた点の数と多様さでしか確かめられない。だから私たちは、立派な仕組みを作るより、気になったネタが集まる場として、エンジニアミートアップをやっています。
- 生成AI
- Slack
- セキュリティ
Claude Code を Deep Research の用途で使うための工夫
こんにちは、newmo の伊藤です。 この記事では、筆者が取り入れている「Claude Code を Deep Research の用途で使うための工夫」について、自作している Skill や端末間での共有方法、Entire の活用事例などを交えて紹介します。 既存のプロダクトが提供する Deep Research 機能に感じていた課題 筆者はこれまで様々なリサーチの用途に ChatGPT や Gemini が提供する Deep Research 機能を利用してきました。これらのプロダクトが提供する Deep Research 機能はとても便利なのですが、以下のような課題も感じていました: 個々のプロダクトが提供しているインターフェース（ウェブやモバイルアプリ）を介するのではなく、普段利用しているターミナルやエディターでリサーチを完結させたい モバイル端末では普段利用している Markdown ビューワー（Obsidian）でリサーチの結果を確認したい リサーチした結果をローカル環境の Markdown ファイルとして直接扱って Git で管理したい Agentic Coding ツールのセッションを管理するために自作しているツールをリサーチの用途でも活用したい 特に、Claude Code をはじめとした Agentic Coding ツールを活用するにつれ、リサーチも Agentic Coding ツールで完結させたいという思いが強くなってきました。 そこで、Claude Code を Deep Research の用途で活用するための環境を整えることにしました。 Claude Code の Deep Research 用 Skill Claude Code を Deep Research の用途で使うために、「必要に応じて Claude Code をリサーチモードに切り替える」ための /mode-researcher という Skill を自作しています。筆者はこのような「必要に応じて Claude Code を特定のモードに切り替えるための Skill」を複数作って活用しており、リサーチの用途以外にも例えば「実装する前にモジュール間のインターフェースやテストを設計するためのモードに切り替える」ための /mode-architect のような Skill も作っています。これらの Skill は、実際になんらかのアクションを起こすための Task content ではなく、Claude Code にナレッジを提供するための Reference content に近い形で定義しています。 実際に /mode-researcher Skill を利用してリサーチを行っている様子は以下のキャプチャのようになっています: /mode-researcher Skill を起動した後、リサーチしたいトピックを入力すると、Claude Code がリサーチのためにいくつかの質問を選択形式で利用者に投げかけてきます。これらの質問に答えると、Claude Code がリサーチを開始して、リサーチしたいトピックにも依りますが概ね 10 分前後でリサーチの結果を Markdown ファイルとして出力してくれます。 /mode-researcher Skill は引数として「リサーチ結果を書き出すための Markdown ファイル」のパスを受け取るようにしています。この引数は、筆者が自身でリサーチ結果を保存するファイル名やディレクトリを指定したいので設けていますが、引数を設けずに Claude Code に自律的にファイル名やディレクトリを決めさせるようにしても良いと思います。 この Skill は Claude Code の利用者側で明示的に起動するためのもので、Claude Code 側で自律的に起動することを想定していません。そのため、SKILL.md の Frontmatter で disable-model-invocation: true を指定して、Claude Code が自律的にこの Skill を起動することを防いでいます。 また、筆者は Claude Code を利用するときは基本的に Plan Mode を利用していますが、この /mode-researcher Skill を利用するときはリサーチ内容を利用者の確認を介することなく Markdown ファイルに出力してほしいので、Plan Mode はあえて利用しないようにしています。 実際の SKILL.md の内容は以下のようになっています: --- name: mode-researcher description: Deep research agent that autonomously searches, analyzes, and synthesizes information into a structured report with citations. disable-model-invocation: true --- This guide defines the workflow for conducting deep, multi-pass research and producing a structured, well-cited report. ## Phase 1: Wait for User Input - Wait for the user to provide the research topic or question right after this skill is invoked. - Do not skip this phase by inferring the topics from the given arguments or filename, instead, must explicitly wait for the user to provide the research topic or question as input. ## Phase 2: Clarify Scope - Use the `AskUserQuestion` tool to ask the user about: - The research topic or question. - Scope, depth, and constraints (time period, domains, perspectives). - Expected output format (length, structure). ## Phase 3: Research Plan - Decompose the topic into 3–8 sub-questions. - ... ## Phase 4: Iterative Search and Analysis - For each sub-question, perform multiple `WebSearch` queries with varied phrasing. - Use `WebFetch` to read full pages, not just search snippets. - Aim for 20–50 search queries total across the session. - Cross-validate claims across multiple independent sources; flag contradictions. - Refine the search strategy as knowledge gaps emerge. - Track every source URL and the claims it supports. - For code-related research, also use GitHub MCP tools (`search_code`, `search_repositories`, `get_file_contents`). - ... ## Phase 5: Synthesis and Report - The output file path should be `$ARGUMENTS`. - Write the report to the specified file with the following structure: - Title - Executive Summary - Table of Contents - Main Sections (with inline citations as HTML anchor tags, e.g. `<a href="URL" target="_blank">source title</a>`) - Conclusions - Sources (list of all referenced URLs with their titles) - Present a brief summary inline after writing the report. - ... ## Principles - Prioritize primary sources over secondary summaries. - Distinguish facts, expert opinions, and speculation. - When sources conflict, present both sides. - Never fabricate sources — every citation must correspond to a real URL that was fetched. - Prefer recent sources unless historical context is relevant. - Use parallel `WebSearch` / `WebFetch` calls for efficiency. - Do not stop after finding one answer — seek corroboration and alternatives. - ... ### Editorial Guidelines - Use HTML anchor tags with target="_blank" for all links (e.g. <a href="URL" target="_blank">text</a>) so they open in a new tab in web browsers. - ... まずは Phase 1: Wait for User Input で、利用者がリサーチしたいトピックを入力する前に Claude Code がリサーチを開始してしまうのを抑制しています。 次に Phase 2: Clarify Scope で AskUserQuestion ツールを利用して、リサーチに関するスコープや深さ、制約条件（時間軸やドメイン、視点など）、期待するアウトプットの形式（長さや構成など）などについて、Claude Code がリサーチを開始する前に利用者に質問するように指定しています。 AskUserQuestion ツールは Claude Code が内包するツールのひとつで、Claude Code が利用者に質問を投げかけて、利用者が選択肢の中から回答を選ぶ形式で入力を受け取るためのツールです。このツールを利用することで、Claude Code が自律的にリサーチの意図を汲んで選択形式で質問を投げかけてくれるため、利用者側の入力の手間を軽減することができています。 Phase 3・4・5 ではリサーチ手順や MCP の活用、アウトプットの形式などを指定しています。 Principles では、「一次情報を尊重する」といったようなリサーチの原則や方針、及び Markdown の書き方に関する細かなガイドラインなどを指定しています。 これらの内容、特に Phase 3・4・5 の内容は、現在も調整を重ねながら運用していますが、概ね筆者が求める使用感・リサーチ内容に近づいてきていると感じています。 端末間でのリサーチの共有 Claude Code は PC 端末で起動していますが、リサーチ結果は外出中にモバイル端末で確認したいことも多いです。筆者はモバイル端末で Markdown ファイルを扱うために Obsidian を利用しているため、リサーチ結果のファイルは Obsidian がアクセスできるクラウドストレージ（筆者の場合は iCloud）上に共有されるように設定しています。 また、筆者は開発環境用に Linux サーバーを構築し、ノート PC などから Tailscale と SSH 経由で Linux サーバーにアクセスして作業する開発スタイルを取っており、Claude Code もこのサーバー上で利用しています。この Linux サーバーにモバイル端末からもアクセスできるように設定して、外出先でもモバイル端末から Linux サーバーにアクセスして Claude Code を用いたリサーチを開始できるようにしています。 モバイル端末（iPhone）から Linux サーバーを操作するためのターミナルアプリは Termius や libghostty ベースで最近話題になっている Echo をはじめとしていろいろなアプリを試していますが、「Control キーを押下したまま他のキーを用いた操作が行いやすい」という観点で Blink Shell というソースが公開されているターミナルアプリを利用しています。 Entire の活用 リサーチ結果について、リサーチ内容を更新するときなど稀に「どのような入力（プロンプト）によってこのリサーチが出力されたのか」という観点も含めて反芻したくなることがあります。 これを実現するために、先日公開された Entire というプラットフォームを試験的に導入しています。 Entire は Agent と人間が協調して開発を進めるためのプラットフォームを目指しており、現在は CLI を用いて Agent とのやりとり（セッション）を記録して、記録したやりとりを可視化するためのウェブサービスを提供しています。 Entire の画面は以下のようになっています: <figure cl
- Claude Code
- 生成AI
- Markdown
- Obsidian