株匏䌚瀟Insight Edgeのブログ - TECH PLAY

TECH PLAY

株匏䌚瀟Insight Edge

株匏䌚瀟Insight Edge の技術ブログ

å…š206ä»¶

こんにちは。Insight Edgeのデザむン郚、共創蚭蚈チヌムの小森谷です。䜏友商事グルヌプの䌁業ではAI掻甚を掚進する組織の䌎走支揎を担圓し぀぀、瀟内の議論の堎づくりや郚門の䌚議䜓蚭蚈などの組織づくりにも取り組んでいたす。 チヌムが拡倧するず、人ず䌚議䜓が増え、それたで暗黙のうちに機胜しおいたやりずりが機胜しにくくなりたす。たずえば、次のような状況はないでしょうか。 定䟋の目的が曖昧で、リヌダヌが䞍圚の週は流䌚になっおいる 同じ話を別の䌚議で2回しおいたり、逆にどの䌚議で扱えばいいか分からない話がある 新しく加わった人が、必芁な情報に぀いお誰に聞けばよいか分からない 私はこれたで耇数の組織で、この状況を経隓しおきたした。この蚘事では、2026幎2月から10月たでにInsight Edgeのデザむン郚で取り組んだ、組織のコミュニケヌションの蚭蚈を玹介したす。個別の䌚議を盎すのではなく、コミュニケヌション党䜓を俯瞰しおから、䌚議ずその間の接続を再蚭蚈した3぀の事䟋です。 蚭蚈の察象は䌚議だけではありたせん。䌚議などの同期のやりずりず、蚘録や資料などの非同期のやりずりを、この蚘事ではコミュニケヌションのパヌツ点ず呌びたす。点は、プロゞェクトや郚、チヌムずいった組織のコミュニケヌションラむン情報が流れる経路。この蚘事では線ず呌びたすの䞊にあり、線が重なっおできる倚局的な党䜓が面です。 事䟋は、共創蚭蚈チヌムの週次定䟋、デザむン郚の2on1ず1on1、デザむン郚䌚郚の党員が集たる月次の䌚の3぀です。手を入れた時期の倧枠の流れは図1のずおりです。 図1: 2月から10月の時間軞。暪の垯ごずに3぀の事䟋を分け、手を入れた時期を瀺した この蚘事でわかるこず 組織のコミュニケヌションを、点ず線ず面で捉えお再蚭蚈した事䟋 最初に点を掗い出し、面で俯瞰しお調敎しながら点や線を蚭蚈する進め方 チヌム定䟋・2on1ず1on1・デザむン郚䌚を運甚しお分かったこず 目次 前提: プロゞェクト単䜍で掻動するチヌム 拡倧フェヌズで起きるこず: 点ず線が増え、重耇ず空癜が生たれる 進め方: 面を描いおから、点ず線を蚭蚈する 事䟋1 チヌムの線: TLが䞍圚でも定䟋が進むようにする 状況2026幎2月〜 面を描いお分かったこず 再蚭蚈したこず 運甚しお分かったこず 事䟋2 線の重なり: 1on1の目的を分け、期埅倀のずれを早く把握する 状況2026幎5月〜 目的を曞いお分かったこず 再蚭蚈したこず 運甚しお分かったこず 事䟋3 郚の線ず党瀟の面: 党瀟の情報の流れの䞭に郚䌚を䜍眮づける 状況2026幎8月〜 面を描いお分かったこず 再蚭蚈したこず 運甚しお分かったこず おわりに: 䌚議を増やす前に、面を描く 前提: プロゞェクト単䜍で掻動するチヌム Insight Edgeのデザむン郚は2025幎4月に発足し、珟圚はサヌビスデザむンチヌムず共創蚭蚈チヌムがありたす。私が所属する共創蚭蚈チヌムは、デザむンのアプロヌチで、支揎先䌁業や瀟内の課題の具䜓化、ワヌクショップの蚭蚈ず運営、事業や組織づくりの䌎走支揎を行っおいたす。デザむン郚党䜓はれネラルマネヌゞャヌGMが、各チヌムはチヌムリヌダヌTLがマネゞメントしおいたす。 共創蚭蚈チヌムの人数は、2026幎2月から9月にかけお2倍に増えたした。メンバヌは基本的にプロゞェクト単䜍で掻動しおいるため、同じチヌムでも、お互いが䜕をしおいるかが芋えにくい状態。点ず線で蚀えば、プロゞェクトの線は日々の業務で自然に維持される䞀方、チヌムの線は意識しお蚭蚈しないず途切れがちです。 拡倧フェヌズで起きるこず: 点ず線が増え、重耇ず空癜が生たれる 2月圓初の共創蚭蚈チヌムでも、冒頭に挙げた3぀の状況が芋られたした。人が増えるず、䌚議や蚘録、資料などの点が増え、プロゞェクトや郚、チヌムずいった線も増えたす。゜フトりェア開発の叀兞『人月の神話』でも知られるように、コミュニケヌションの経路の数は「人数×人数−1÷2」で増えるため、人数が2倍になるず、経路は4倍以䞊に増えたす図2。これはチヌムの䞭だけで数えた本数で、メンバヌはそれぞれプロゞェクトや郚の線にも属しおいるため、実際に行き亀う経路はさらに倚く、盞手も倚様になりたす。 図2: 人数ず、チヌムの䞭の経路の数人数は䟋 線が増えるず、同じ話が2぀の点を流れる重耇ず、どの点でも扱われない空癜が生たれたす。新しく加わった人が誰に聞けばよいか分からないのも、盞談先や資料ずいう点がどの線䞊にも䜍眮づけられおいない状態です。原因は䌚議の数ではなく、点ず線の重なり方や぀ながり方が蚭蚈されおいないこずにあるず考えたした。 目指したのは、散らばった点を、点ず線ず面で捉えお線み盎すこずです図3。目暙は、メンバヌ䞀人ひずりがこの面を俯瞰でき、必芁な情報・盞談先・刀断基準などの共通認識をもっお自埋的に動ける状態ずしたした。 図3: 散らばった点を再蚭蚈し、必芁な情報・盞談先・刀断基準を共有できる状態にする 進め方: 面を描いおから、点ず線を蚭蚈する 具䜓的なプロセスずしおは、䌚議䜓を察象チヌム/個人ず期間䞭短期/䞭長期の2軞に眮き、点ず点を結ぶ矢印で関係を描くこずで敎理を進めたした図4。䞀枚に描くず、組織のコミュニケヌション党䜓が芋え、重耇や空癜が分かりたす。描き方は組織の単䜍で倉えたす。チヌムや郚ではこの2軞で描き、党瀟では情報が䞊がる流れず䞋りる流れで描いおいきたした事䟋3。 図4: 面を描く枠組み。4぀の区分に䌚議を眮き、矢印で関係を結ぶ 最初に、組織の点を掗い出したすたずは䌚議䜓: 同期コミュニケヌション。そのあずは、面で俯瞰しお調敎するこずず、面を芋ながら点や線を蚭蚈するこずを埀埩したす図5。前者は党䜓の配眮を決める䜜業、埌者は䜍眮づけが決たった点ごずに䞭身を決める䜜業です。 面で俯瞰しお調敎するずきは、次の3぀を順番を決めずに、同時に進めたす。 点ごずに、目的なぜ行うかを蚀語化する 目的を面の䞊にマッピングし、重耇や空癜を調敎しながら点を配眮し盎す 点ず点を線で぀なぐ蚘録や資料などの非同期の点を含む 䜍眮づけが決たった点から、面を芋ながら、スコヌプ誰を、どの時間軞で扱うかずプロセス前埌の情報の接続ず、蚘録の保存先を蚭蚈したす。1回で敎うこずは少なく、蚭蚈しおみるず違和感が出おきたす。その違和感を俯瞰に戻し、目的・配眮・線を調敎し盎しお、蚭蚈の粟床を高めたす。 図5: 最初に点を掗い出し、俯瞰での調敎ず点ごずの蚭蚈を埀埩する 必芁なのは、最初に俯瞰しお面を描く時間をずるこずず、敎理が完党でない段階でも運甚を始め、運甚しながら盎す刀断だず考えおいたす。ここから先は、この手順で再蚭蚈した3぀の事䟋を、手を入れた順に玹介したす。 事䟋1 チヌムの線: TLが䞍圚でも定䟋が進むようにする 状況2026幎2月〜 2月の時点では、週次の定䟋にTLが䞍圚の週は流䌚になりがちでした。堎の目的は決たっおいたものの、メンバヌに十分䌝わっおおらず、参加者が必芁性を実感しおいなかったこずが芁因だず考えおいたす。定䟋で扱われない話題は、ひずたず1on1に持ち蟌たれる傟向もありたした。 面を描いお分かったこず チヌムの䌚議を2軞に眮いお面を描くず図6、個人×䞭長期、぀たり目暙や期埅圹割を扱う点が曖昧でした。 図6: 2月時点のチヌムの䌚議䜓。個人×䞭長期を扱う䌚議の䜍眮づけが曖昧だった 再蚭蚈したこず 2月から10月にかけお再蚭蚈を重ねおたどり着いた珟圚地が、図7です。䜍眮づけが曖昧だった個人×䞭長期の区分には、事䟋2で説明する2on1ず1on1を眮きたした。定䟋で䞭短期の芖点から話したこずは、四半期のふりかえり䌚で䞭長期の芖点から捉え盎したす。 図7: 10月時点。2on1ず1on1を新蚭し、䞭短期から䞭長期ぞの捉え盎しを矢印で瀺した 䌚議ずいう点だけでなく、蚘録ずいう点も蚭蚈したした。3月に、䌚議以倖も含めたチヌムの情報をチヌムのマスタヌ資料ずしお1か所に集玄し、立ち戻る堎所、自走する仕組み、俯瞰する芖点の3぀の圹割を持たせたした図8。 定䟋では、各自が近況をチェックむンずしおマスタヌ資料に曞いおその堎で読み合い、決定事項も同じ資料に残したす。䌚議に出おいない時期のこずも資料を読めば远え、進行者が誰でも同じ手順で進められたす。この圢で4月から運甚を始めたした。 図8: マスタヌ資料に持たせた3぀の圹割立ち戻る・自走する・俯瞰する 運甚しお分かったこず 運甚を始めおからは、TLが䞍圚の週も流䌚にならず、い぀もどおり定䟋を進められるようになりたした。8月には定䟋を、チェックむン、実践事䟋の共有、TLからの連絡の3郚構成に倉曎。珟圚も小さな改善を重ねおいたす。 2月の蚭蚈では、チヌム×䞭長期の点ずしお半期に1回の半日のオフサむトを眮いおいたしたが、3月に実斜するず、準備ず運営の負荷が倧きく、人数が増えるず半日では足りないこずが分かりたした。そこで、定䟋の拡倧版ずしお四半期に1回のふりかえり䌚に倉曎したした。それぞれの堎の目的をあらかじめ共有しおいたため、䜕を倉え、䜕を維持するかを刀断しやすかったず考えおいたす。 事䟋2 線の重なり: 1on1の目的を分け、期埅倀のずれを早く把握する 状況2026幎5月〜 5月に、デザむン郚でGMずメンバヌの1on1が新たに定矩されたした。GMから瀺された「堎の目的」には、幎間の成果ず評䟡の目線合わせや、䌚瀟や郚ぞの゚ンゲヌゞメントなど、性質の違う耇数の目的が含たれおいたした。チヌムには既にTLずの週次の1on1があり、目的の䞀郚が重なりそうでした。郚の線ずチヌムの線が、同じメンバヌを察象にした1on1で重なる圢です図9。 図9: 郚の線ずチヌムの線が重なる1on1を、目的ごずの3぀の点に分けた 目的を曞いお分かったこず GMずの1on1の目的を分解しおみるず、扱う話題が2皮類あるこずが分かりたした。目暙や評䟡芳点の認識を揃える話ず、䌚瀟の方針ず自分の仕事を接続する話です。 前者はGMずTLの芳点を同じ堎で揃える必芁があるため、メンバヌ・GM・TLの3人による2on1にしたした。埌者は経営に近いGMず1察1で話すため、GMずの1on1にしたした。いずれも4週に1回です。TLずの週次の1on1は日々の業務支揎ずしお残し、個人を察象ずする点を3぀に敎理したした。この敎理を、目的ごずに堎を分けお再蚭蚈する案ずしおGMに提案したずころ、「やっおみよう」ずいう流れになりたした。 再蚭蚈したこず 2on1で䜿う蚘入シヌトは、䌚瀟の目暙蚭定の項目ず察応する圢で䜜成し、たずは自分自身で詊行しおみたした。自分で曞いおみるず、目暙や評䟡芳点の認識合わせを3人が30分で話すには扱いきれない量だったため、毎回確認する項目を6぀の問いに絞り、1シヌトで進める簡易的なプロセスにしたした図10。 図10: 2on1の30分の構成。メンバヌ・GM・TLの3人で、6぀の問いを5分ず぀確認する 運甚しお分かったこず この2on1ず1on1は、3぀の事䟋の䞭で最も効果を䜓感できたした。GMずTLの芳点を4週ごずに同じ堎で照合するこずで、期埅倀のずれを早い段階で把握し、修正しやすくなったず感じおいたす。効果が出た理由は、堎の目的を分解しお絞り蟌んだ䞊でプロセス蚭蚈したこずにあるず考えおいたす。䟋えば営業組織では、数字を基準に䌚話できたす。デザむン郚にはそうした指暙が少ないため、䞁寧な目線合わせが必芁だず改めお感じたした。 2on1ず1on1は、6月にデザむン郚党䜓でたずやっおみる圢で始め、同じ月に、その蚭蚈を党瀟の朝䌚瀟員党員が集たる堎で共有したした。9月にはTLが、実践を螏たえお蚘入シヌトの雛圢を曎新し、チヌムの運甚に合わせた圢で䜿い始めたした。 事䟋3 郚の線ず党瀟の面: 党瀟の情報の流れの䞭に郚䌚を䜍眮づける 状況2026幎8月〜 デザむン郚䌚は、2026幎4月から䌑止しおいたした。2025幎床は、事前のアゞェンダがなく堎の目的が䞀貫しにくい、倚忙なメンバヌが参加できない、進行が特定のメンバヌに䟝存する、ずいう課題がありたした。6月にTLぞのヒアリングで前幎床をふりかえり、7月にGMを亀えお再開の方針を敎理したしたが、ほかの䌚議䜓ずの関係で、郚䌚が担う圹割はただ曖昧でした。 そこで8月の再開初回は、圹割を決める前に、たず郚の珟状を把握する回ずしお、最近加わったメンバヌの「知りたいこず」を扱いたした。事前にシヌトで「玠朎な疑問」を集め、圓日の50分でGMずTLが回答する圢匏です。メンバヌから11件の疑問が集たり、回答の倚くは既存資料の案内で枈みたした。぀たり、情報がなかったのではなく、所圚が䌝わっおいなかったのです。 面を描いお分かったこず 集たった疑問を党瀟の面に䜍眮づけおみるず、デザむン郚に固有の疑問は11件のうち3件。残りの8件は、「プロゞェクトの進捗は、どの経路で䞊に䌝わっおいるのか」のような、党瀟に共通する仕組みに぀いおの疑問でした。そこで、郚䌚の倖偎にある党瀟の䌚議䜓ず、その間の情報の流れを敎理したした図11。 党瀟には、珟堎の情報ず論点が経営ぞ䞊がる流れず、経営の方針ず刀断が管理職の定䟋を経お䞋りる流れがありたす。郚䌚は、䞋りる流れの䞊で、チヌムの定䟋や郚内のGM・TLの䌚議ず䞊ぶ月次の点ずしお䜍眮づけたした。 図11: 党瀟の情報の流れを敎理し、郚䌚が担う圹割を決める䌚議名は䞀般化した暡匏図 再蚭蚈したこず この敎理を螏たえお、9月にGM・TLず目的を決めたした。「各メンバヌの掻動を共有する堎」から「組織方針の背景ず論点を共有し、理解を浞透させる堎」に倉え、個別案件の進捗や個人の評䟡などは扱わないこずにしたした。進め方は月1回60分で、冒頭の10分で䌝達、残りの50分で質疑ず議論を行いたす。 10月からは、毎週の郚内のGM・TLの䌚議でテヌマの候補を䞀芧に曞き足し、郚䌚の2週間前に次回のテヌマず話し手を確定する流れも仕組みにしたした。 あわせお、1on1で出た疑問から郚に共通するテヌマをGMずTLが抜出し、郚䌚で背景を共有しお、再び1on1で扱う埪環を蚭蚈したした。抜出では、1on1の内容をそのたた共有せず、話したメンバヌの意向ず共有範囲に配慮したす。 運甚しお分かったこず 再開初回ず9月の回を実斜し、郚䌚を回す枠組みは敎いたした。8月の再開初回のあずのアンケヌトでは、「他の人の質問ず回答からも理解が深たった」ずいう声がある䞀方で、「時間が足りず、運甚や蚀葉の定矩たで螏み蟌めない」「人数の倚い察面の堎では発蚀しづらい」ずいう課題も挙がりたした。 9月の回は、これらの課題を螏たえお議論するテヌマを絞り、口頭で発蚀しにくい人も意芋を出せるようにチャットを䜵甚したした。圓日は、日々ずもに仕事をする䜏友商事のデゞタル・AI戊略である DAIS を読み解いたうえで、デザむン郚のあり方に぀いお議論したした。 毎月のテヌマ抜出方法も仕組み化しお敎備したので、10月以降は䞀旊ルヌティンずしお回しおいく予定です。 おわりに: 䌚議を増やす前に、面を描く この期間で倉化を確認できたのは、2on1ず定䟋です。郚䌚は枠組みを敎えた段階で、成果の確認はこれからです。それでも、点ごずに目的を曞いたこずで、既存の䌚議ずの圹割の違いを確認でき、新しい点の䜍眮づけも説明しやすくなりたした。 取り組みは、いた2぀の方向に広がり始めおいたす。経営局やGMが来期以降の方針を議論する集䞭蚎議の蚭蚈に関わるなど、堎のレむダヌを䞊げる方向。そしお、点ず線で面を蚭蚈する察象を、瀟倖の䌎走支揎プロゞェクトなどに広げる方向です。面を描き盎し、点の目的を芋盎し続けられる状態を目指すこずは、さたざたな堎に応甚できそうだず感じおいたす。 なお、今回ご玹介したような再蚭蚈は、私䞀人で進めたものではありたせん。デザむン郚のGM、共創蚭蚈チヌムのTLず、点の目的や線の぀なぎ方を議論しながら決めおきたした。メンバヌからも、郚䌚のアンケヌトで進め方の改善案が寄せられ、次の回の蚭蚈に取り入れおいたす。案を出し、議論しお決め、運甚しお盎す。この埀埩を繰り返すこず自䜓が、組織のコミュニケヌションの面を関係者ず䞀緒に描き盎す共創になっおいるず感じおいたす。 䌚議を1぀増やしたくなったずきが、面を描いおみるよい機䌚です。皆さんの組織では、どの線が途切れやすく、どの点に重耇や空癜があるでしょうか。いたある䌚議ず蚘録を䞀枚に䞊べお眺めるずころから、ぜひ詊しおみおください。この蚘事が、チヌムの䌚議や雑談で、組織のコミュニケヌションに぀いお話すきっかけになれば嬉しく思いたす。
はじめに こんにちは、Insight Edgeの小林たさみ぀です。 ※ 本蚘事はPoC案件での技術怜蚌の内容であり、商甚環境での実甚性は今埌の怜蚌課題です Claude Codeのようなコヌディング゚ヌゞェントに実装を任せる堎面は珍しくなくなりたした。䞀方で、実装を任せたあずの「意図どおりに動いおいるかを確認する」「レビュヌする」「マヌゞしお埌片付けをする」ずいった䜜業は、人の手に残りがちです。 今回は、あるPoC案件の開発で、タスクの起祚からレビュヌ、マヌゞ䟝頌たでをAI゚ヌゞェントに任せる仕組みを䜜っお運甚したした。本蚘事では、背景、蚭蚈の考え方であるハヌネス゚ンゞニアリング、具䜓的な仕組み、導入結果ず今埌の課題を玹介したす。 なお、本蚘事は実務で行った内容をもずにしおいたすが、案件を特定できないよう、案件の内容はがかしお曞いおいたす。 TL;DR タスクの起祚、蚭蚈、実装、レビュヌ、マヌゞ䟝頌、埌片付けをAI゚ヌゞェントに任せ、人は「planずDRのレビュヌ」ず「マヌゞ」の刀断だけを担圓した 仕組みで匷制する制玄( deny 、フック、CI)ず、プロンプト偎で芏定する振る舞い(レビュヌの3分類など)を分けお蚭蚈した PoCでの成果であり、商甚の開発で通甚するかは今埌の怜蚌課題 目次 背景 ハヌネス゚ンゞニアリングを掻甚した開発 具䜓的な仕組み 導入結果 今埌の課題 たずめ 参考文献 背景 察象は、ドキュメントを分析し、意思決定を支揎するレポヌトを䜜るPoCです。バック゚ンドはFastAPI、フロント゚ンドはReact、分析はクラりド䞊のLLMを䜿ったマルチ゚ヌゞェントで行っおいたす。 このPoCでは、次の状況が重なっおいたした。 他案件のリリヌスず時期が重なり、人手が足りない 開発者が1人のため、コヌドレビュヌをする人がいない 開発タスクが60件を超え、どれも「worktreeを切る → 実装 → PR → レビュヌ → マヌゞ → 埌片付け」ずいう同じ䜜業の繰り返しになる 䞀方で、PoCなので芁件が限られおおり、詊したい手法をすぐ怜蚌できる立堎でもありたした。そこで、定型䜜業をたずめおAIに枡し、人は「䜕を䜜るか」の刀断に集䞭する圢を目指したした。 実際にどの皋床の範囲を回したかは、タスクの内蚳で䌝わりやすいず思いたす。認蚌認可、セキュリティ察策、性胜ずコストの改善、テスト戊略ずE2Eテスト、むンフラのコヌド化ずCI/CD、アクセシビリティの改善ずいった、機胜芁件から非機胜芁件、DevOpsたで幅広い領域が含たれたす。これらすべおのタスクを、この仕組みで進めたした。 ハヌネス゚ンゞニアリングを掻甚した開発 この仕組みを蚭蚈するうえで参考にしたのが、Birgitta Böckelerさんの蚘事 Harness engineering for coding agent users (martinfowler.com、2026幎4月)です。 Agent = Model + Harness 蚘事では、゚ヌゞェントを「Agent = Model + Harness」ず捉えたす。ハヌネスずは、モデル以倖のすべお、぀たり゚ヌゞェントを取り巻く仕組みのこずです。゚ヌゞェント補品に最初から組み蟌たれた郚分(inner harness)ず、利甚者が自分のナヌスケヌス向けに䜜る郚分(outer harness)があり、本蚘事で扱うのは埌者です。 outer harnessは、2皮類の制埡で構成されたす。 ガむド ゚ヌゞェントが動く前に方向づける(feedforward) センサヌ 動いた結果を芳枬し、自己修正させる(feedback) さらに、それぞれを次の2皮類に分けお考えられたす。 computational 機械的に決たる。テスト、リンタヌ、暩限蚭定など inferential LLMの刀断に頌る。レビュヌや方針の蚘述など 人の圹割は、同じ問題が繰り返されたずきに、ガむドずセンサヌを改善しお゚ヌゞェントを操るこずです。 この関係を、本蚘事の内容に圓おはめお図にするず次のようになりたす。 ハヌネス抂芁 この図は、Böckelerさんの蚘事にある図を、本プロゞェクトの郚品で描き盎したものです。原兞の図は 蚘事 で確認できたす。 人がやるこず、AIがやるこず ハヌネスで呚囲を固めたうえで、人の仕事は「刀断」に絞りたした。 担圓 やるこず 人 起祚の指瀺、着手の指瀺、planファむルずDecision Recordのレビュヌ(重芁なタスクはテストケヌスも確認)、マヌゞ、必芁に応じたデプロむ䜜業 AI 芁望の分解ず調査、Issueの起祚、カンバンの移動、蚭蚈、実装、テスト、PR䜜成、デモ動画の撮圱ず添付、レビュヌず指摘察応、マヌゞ䟝頌、worktreeなどの埌片付け Decision Record(DR)は、意思決定の理由ず採甚しなかった代替案を残すためのMarkdownです。タスクごずにAIが曞き、人が読んで方針を確認したす。 このプロゞェクトの郚品を䞊べる 本プロゞェクトの郚品を、ガむドずセンサヌ、computationalずinferentialの2軞で敎理するず次のようになりたす。各郚品の詳现は、次章で玹介したす。 computational(機械的) inferential(LLMの刀断) ガむド (事前) settings.json の deny でPRのマヌゞを犁止、レビュヌ系゚ヌゞェントに曞き蟌みツヌルを䞎えない、worktreeによる䜜業の分離 CLAUDE.md の蚭蚈原則ずコメント芏玄、DRのテンプレヌト、Issueの「やらないこず」 センサヌ (事埌) 線集埌のformatフック、コミット時のシヌクレット怜査、CI(lint、単䜓テスト、E2E、ビゞュアルずa11yの怜査、ラむセンス怜査)、PRぞのカバレッゞコメント、ミュヌテヌションテスト レビュヌ指摘の3分類、デモ動画の比范 この衚を䜜るず、䜕が「匷制」で䜕が「玄束」なのかが芋えたす。実際には、仕組みで匷制できおいるのは、 deny 、ツヌル暩限、シヌクレット怜査、CIだけです。ルヌプの3ラりンド䞊限や、指摘の3分類、Slack通知の条件は、プロンプトに曞いた玄束にすぎたせん。この線匕きをどう考えるかは、 今埌の課題 で觊れたす。 具䜓的な仕組み 構成 構成は、Claude Codeのスキル2぀( /create-task 、 /run-task )ず、サブ゚ヌゞェント3぀(plan゚ヌゞェント、dev゚ヌゞェント、review゚ヌゞェント)です。 ゚ヌゞェントのワヌクフロヌ ポむントは、゚ヌゞェント同士が盎接やり取りしないこずです。叞什塔(Orchestrator、 /run-task )が SendMessage で仲介するため、各゚ヌゞェントは自分の圹割だけを芋ればよくなりたす。たた、Claude Codeのサブ゚ヌゞェント機胜を利甚するこずで、コンテキストを分離し぀぀、必芁な情報を共有できたす。 1タスクの流れ 党䜓の流れは次のずおりです。人が関わるのは、planずDRのレビュヌず、最埌のマヌゞだけです。 起祚( /create-task ) 芁望を分解し、コヌドベヌスを䞊列に調査しお既存Issueずの重耇を刀定したす。続いお、遞択匏の質問で芁件を固め、優先床ずストヌリヌポむントを芋積もりたす。最終確認を取ったうえで、固定の節構成(背景・目的、芁件、やるこず、やらないこず、䟝存関係)ず固定のラベル(優先床、ストヌリヌポむント、倉曎察象項目など)でIssueを起祚し、カンバンに登録したす。「やらないこず」を明蚘しおおくず、埌のレビュヌで範囲の逞脱を怜出できたす。 たずえば、次のように芁望を䞀蚀䌝えるだけで起祚されたす。以䞋は、実際に起祚されたIssueの䟋です(䞀郚をマスクしおいたす)。 /create-task 画面サむズが倧きいず䜙癜が目立぀。芋づらいので幅をディスプレむサむズに応じお調敎したい 起祚されたIssue 蚭蚈(plan゚ヌゞェント) Issueを確認し、䜜業甚のworktreeずブランチを䜜りたす。カンバンを「進行䞭」に移し、planファむルずDRを曞きたす。planが完了するたで実装は始めたせん。人が確認するポむントはここです。正しい蚭蚈が行われおいるかをレビュヌし、必芁に応じお修正指瀺を出したす。問題が無くなれば、実装フェヌズに進みたす。 planファむルには、背景ず芁件の芁玄、蚭蚈方針の結論、ファむル単䜍の実装ステップ、テスト方針、そしお「蚭蚈䞊の懞念点・刀断が分かれる点」を曞かせたす。最埌の項目は、人がレビュヌするずきの着県点になりたす。DRには、背景、決定事項ずその理由、怜蚎した代替案ず採甚しなかった理由を残したす。埌から「なぜこうなっおいるのか」をたどるための蚘録です。 実装(dev゚ヌゞェント) planに沿っお実装したす。テストは必須で、LLM呌び出しのみ時間ずコストの兌ね合いからモックにしたす。formatずテストを通しおからPRを䜜り、PRの先頭行にIssueを閉じる蚘法を曞いおカンバンず連動させたす。さらに、人のレビュヌをしやすくするために、倉曎前埌の画面を䞊べたデモ動画を録画しおPRに添付したす。埌段のレビュヌ指摘を受け取った際、内容に同意できない堎合は、反論しおよいこずにしおいたす。 䞀方で、force push、マヌゞ、Issueの「やらないこず」ぞの着手は犁止です。 PRに添付されたデモ動画。巊が倉曎前、右が倉曎埌 レビュヌ(review゚ヌゞェント) 次の8芳点をレビュヌしたす。 シヌクレットの混入 「やらないこず」ぞの逞脱 芁件の充足 アヌキテクチャ方針が適切か テストの有無ず劥圓性 Decision Recordが適切に蚘録されおいるか 実装品質 セキュリティ これに加えお、デモ動画の挙動がIssueの芁件ず䞀臎しおいるかも確認したす。ルヌプは最倧3ラりンドで、反論が2埀埩続いた堎合は打ち切っお人に刀断を仰ぎたす。これは過剰な議論や実装を防ぐための仕組みです。詊しにラりンド数に制限をかけずに運甚しおみたずころ、4ラりンド以降は些现な指摘が延々ず続き、効率が倧幅に䜎䞋したした。そのため、3ラりンドを䞊限ずしたした。 reviewer゚ヌゞェントが投皿したレビュヌコメントの䟋 マヌゞず埌片付け レビュヌが承認されるず、SlackのIncoming Webhookにより通知が届きたす。人が内容を確認しおマヌゞするず、叞什塔がマヌゞを確認し、worktree、ロヌカルブランチ、リモヌトブランチを削陀しお main を曎新したす。マヌゞだけは人が握り、それ以倖は自動で片付く蚭蚈です。たた、Slackのメッセヌゞには远加で察応が必芁な事柄(䟋えば、むンフラリ゜ヌスの倉曎など)も含めるようにし、䜕をすれば良いかが䞀目でわかるように工倫しおいたす。 実装䟋computationalなガむドずセンサヌ 匷制力のある郚分は、蚭定ファむルに数行曞くだけで実珟できたす。たずえば、PRのマヌゞを゚ヌゞェントに犁止し、ファむルを線集するたびに自動でフォヌマットをかける蚭定は、 .claude/settings.json に次のように曞きたす。 { " permissions ": { " deny ": [ " Bash(gh pr merge:*) " ] } , " hooks ": { " PostToolUse ": [ { " matcher ": " Edit|Write|MultiEdit ", " hooks ": [{ " type ": " command ", " command ": " mise run format " }] } ] } } deny はプロンプトでの「マヌゞしないでください」ず違い、゚ヌゞェントがこのコマンドを実行できなくなりたす。実は最初の版では、review゚ヌゞェントが承認埌に自動でマヌゞしおいたした。マヌゞだけは人が握る、ずいう方針をルヌルずしお曞くのではなく、仕組みで担保した䟋です。 --- name : review description : dev゚ヌゞェントが䜜成したPRをレビュヌし、承認時は叞什塔ぞ報告する。マヌゞは行わない。 tools : Bash, Read, Glob, Grep, SendMessage model : opus --- コミット時のシヌクレット怜査(pre-commit)は、あえお怜査を1぀に絞っおいたす。敎圢や単䜓テストは数十秒かかり、コミットのたびに走らせるには重いためです。フックが守るのは、䞀床コミットするず履歎から消すのが極めお高コストな「シヌクレット」だけにし、残りはCIに任せおいたす。CIず同じコマンド、同じgitleaksのバヌゞョンを䜿うため、フックが通ればCIでも通りたす。なお、前述のPostToolUseフックにより、ファむルを線集するたびに自動でフォヌマットがかかるようになっおいるため、基本的にはCIでLinter/Formatterによる倱敗は起こりたせん。 #!/bin/sh set -e exec mise run scan:secrets:staged センサヌの事䟋①指摘を握り぀ぶさせない3分類 最初のレビュヌの運甚では、「軜埮な指摘ならAPPROVEしおコメントを残す」ずいう䜙地がありたした。その結果、マヌゞ枈みの3タスクで、10件以䞊の指摘が誰にも察応されないたた残りたした。「任意察応」は、誰も察応しないこずの䞁寧な蚀い換えでした。 そこで、レビュヌの指摘を必ず次の3぀のどれかに分類するようにしたした。「任意」ずいう分類は䜜りたせん。 分類 刀断 扱い 狙い 芁修正 このPRの目的や品質に必芁 このPRで盎す 品質を守り、芁件を満たす 別タスク化 重芁ではないが、いずれ盎すべき 優先床を䞋げおIssueを起祚する レビュヌ負荷の軜枛ず、過剰な実装の防止 取り䞋げ 些现で、盎しおも䟡倀がほずんどない 理由を曞いお撀回する 些现な察応の繰り返しによる、フロヌの長期化ず無駄な実装の防止 「別タスク化」には、いたは過剰でも将来あるずよい改善も含めたす。起祚が終わるたでは、Slack通知もマヌゞもできない流れにしたした。これで、指摘が攟眮されるこずも、些现な指摘でPRが延々ず埀埩するこずも枛りたした。 review゚ヌゞェントのプロンプトには、次のように曞いおいたす(抜粋)。 すべおの指摘は、次の3分類のいずれかに必ず割り圓おたす。 「任意察応」「参考」「奜みの問題」「䜙力があれば」ずいった曖昧な分類を䜜るこずを犁止したす。曖昧な分類は、察応されないこずを䞁寧に蚀い換えただけで、実質的に指摘を捚おおいたす。 「取り䞋げ」を分類に甚意しおいるのは、指摘の氎準に達しない些现な気づきを無理に起祚させないためです。すべおを別タスク化するず起祚が膚匵し、Projectsのボヌドが機胜しなくなりたす。 盎す䟡倀があるかを自分に問い、無ければ取り䞋げおください。 犁止する分類の名前たで具䜓的に列挙し、「なぜ犁止するのか」「なぜこの分類が必芁なのか」ずいう理由を添えおいる点がポむントです。理由を曞いおおくず、゚ヌゞェントが想定倖のケヌスに出䌚っおも、意図に沿っお刀断しおくれたす。刀定は「芁修正が1件でもあればREQUEST_CHANGES、0件ならAPPROVE」ず機械的に決たるようにし、別タスク化を提案した指摘は、GitHubのレビュヌ本文にも「別タスク化を提案」ず明蚘させおいたす。レビュヌを読んだ人が、その指摘が攟眮されたのか、起祚されたのかを刀別できるようにするためです。 センサヌの事䟋②䜿い捚おのデモ動画 もう䞀぀のセンサヌが、デモ動画です。PRのベヌスずなるコミットず、PRのブランチを䞊べお録画し、PRに添付したす。コヌドを読むだけでは気づきにくい「芋た目や動きの食い違い」を、レビュヌ時に確認できたす。動画は䜿い捚おで、リポゞトリにはコミットしたせん。 工倫①圹割ごずにモデルを倉える ゚ヌゞェントごずに、䜿うモデルを倉えおいたす。 ゚ヌゞェント モデル 理由 plan fable 蚭蚈の質が埌工皋の品質を決める dev sonnet 蚭蚈どおりにコヌドぞ萜ずす䜜業のため review opus 品質を担保したいが、最䞊䜍のモデルではコストが高すぎるため、折衷案ずした 工倫②運甚の手間を枛らす 人ず゚ヌゞェントの手䜜業を、自動化ず怜出に眮き換えたした。 カンバンの移動 カンバンの「Todo → 進行䞭」だけは、plan゚ヌゞェントが移したす。残りはGitHub Projectsの自動化に任せおいたす。PRの先頭行にIssueを閉じる蚘法があれば「レビュヌ䞭」ぞ、マヌゞされれば「完了」ぞ移りたす。 Slack通知 通知は1タスクに぀き1通に絞りたした。送る条件は、レビュヌがAPPROVEであるこず、別タスクの起祚が終わっおいるこず、PRがマヌゞ可胜な状態( MERGEABLE か぀ CLEAN )であるこず、の3぀がすべお揃ったずきです。なお、MCP経由で投皿するず投皿者が自分自身になり、通知が鳎りたせん。そのため、Slack Appを䜜り、Incoming Webhook経由で投皿しおいたす。 投皿はシェルスクリプトに閉じ蟌めおいたす。Webhook URLを取埗し、このスクリプトの䞭でだけ扱うこずで、URLがシェル履歎や䌚話ログに残らないようにしおいたす。゚ヌゞェントには、このスクリプトの実行だけを蚱可したす。 #!/usr/bin/env bash set -euo pipefail WEBHOOK_URL = " <YOUR_WEBHOOK_URL_HERE> " RESPONSE = " $( curl -sS -X POST -H ' Content-type: application/json ' \ --data @ " $1 " " $WEBHOOK_URL " ) " unset WEBHOOK_URL [ " $RESPONSE " = "ok" ] || { echo " Slackぞの送信に倱敗: ${RESPONSE} " >&2; exit 3 ; } 通知の本文には、マヌゞコマンドず、マヌゞ埌に人がやるこずも含めたす。たずえばむンフラの倉曎を䌎うPRなら、「マヌゞ埌にterraform applyを実行し、実環境で確認する」ずいった手順たで曞いおあるため、通知を開いた時点で䜕をすればよいかが分かりたす。 Slackに届くマヌゞレビュヌ䟝頌の通知 コンフリクト 最初は、䞊行しお進めるタスクのうちコンフリクトしそうな組を事前に予枬しようずしたしたが、予枬は倖れたした。そこで、予枬をやめお怜出に切り替えたした。人から1件のマヌゞ報告を受けるたびに、叞什塔が残りのPRに぀いお次のコマンドを実行したす。 for n in { 残っおいるPR番号 } ; do gh pr view $n --json number,mergeable,mergeStateStatus done 結果が MERGEABLE ならそのたた進め、 CONFLICTING ならdev゚ヌゞェントにコンフリクトの解消を䟝頌したす。 UNKNOWN は、GitHubがただ刀定を蚈算䞭の状態です。これをコンフリクトず誀認するず䞍芁な取り蟌みを䟝頌しおしたうため、数秒埅っおから再取埗するようにプロンプトに明蚘しおいたす。解消はrebaseではなくmergeで行いたす。rebaseはforce pushが必芁になり、dev゚ヌゞェントに犁止しおいるルヌルずぶ぀かるためです。同じPRで解消に2回倱敗した堎合は、別の倉曎を壊しおいる可胜性があるため、人に゚スカレヌションしたす。 導入結果 数倀 0.8人月での開発実瞟は次のずおりです。 項目 倀 マヌゞしたPR(bot陀く) 86本 PR䜜成からマヌゞたでの時間 䞭倮倀 箄0.8時間、平均 箄2.6時間 テストコヌドずプロダクトコヌドの行数比 箄1.7倍 人の工数 1タスクあたり平均 箄15分 実装枈みの䞻な機胜/非機胜は次のずおりです。 区分 䞻な内容 機胜芁件分析 耇数の芳点での分析ず集玄、远加の質問チャット、根拠箇所ぞのトレヌサビリティ、远加資料での再分析ずバヌゞョン管理、倱敗分だけの再実行 機胜芁件レポヌトずUX 経枈性シミュレヌション、リスク泚蚘、履歎の怜玢、PDF・JSONの入出力、ブラりザを閉じおも続く分析ず進捗配信、ダヌクモヌドずアクセシビリティ察応 非機胜認蚌ずセキュリティ MFA蟌みの認蚌認可ずナヌザヌ管理、LLM認蚌の鍵レス化、保存デヌタの暗号化、シヌクレット・ラむセンス怜査 非機胜性胜ずコスト プロンプトキャッシュず圧瞮、ストリヌミング化、リトラむ、分析結果の氞続化 非機胜品質保蚌 単䜓テスト、E2E、ビゞュアルリグレッションずa11yの自動監査、ミュヌテヌションテスト DevOps・基盀 Terraformによるむンフラのコヌド化、GitHub ActionsのCI、mainマヌゞでの自動デプロむ、䟝存曎新の自動化 定性的な倉化 人がやるこずは、「䜕を䜜るか」ず「planずDRのレビュヌ」に絞られたした。他案件の察応ず䞊行しながらでも、この案件を止めずに進められたのが倧きな倉化です。 今埌の課題 良い点だけでなく、残っおいる課題や今埌怜蚌したい点も挙げおおきたす。 蚭蚈ず適甚範囲 AIの凊理時間ずレヌトリミット 人の工数は小さくなりたしたが、PRが出るたでの時間は、AIの凊理時間ずレヌトリミットに瞛られたす。蚭蚈、実装、最倧3ラりンドのレビュヌ、デモ動画の録画にはそれぞれ時間がかかりたす。䞊行しお回すタスクは最倧5件を目安にしおいたすが、増やすほどレヌトリミットにぶ぀かりやすくなりたす。たた、䞊行するPRが増えるほど、コンフリクトの確率も䞊がりたす プロンプト䞊のルヌルをどこたで仕組みで匷制するか 仕組みで匷制できおいるのは deny 、ツヌル暩限、シヌクレット怜査、CIだけで、ルヌプの3ラりンド䞊限、指摘の3分類、Slack通知の条件はプロンプトに曞いた玄束にすぎたせん。PoCではこれで十分でしたが、商甚開発に適甚するなら、ここが最初の論点になるず考えおいたす 商甚開発でも同じ圢が通甚するか 今回のPoCは芁件が限られおおり、効率を最優先できたした。品質や監査の芁求が高い商甚開発で、同じ人の関䞎の床合いでよいかは、今埌の怜蚌課題です 運甚䞊の課題 dev゚ヌゞェント、review゚ヌゞェント、人が同じGitHubアカりントを䜿っおいるため、GitHub䞊の承認が圢匏的になりやすい。実際、自分のPRにはGitHubの機胜におけるAPPROVEができず、コメントで代甚しおいる ミュヌテヌションテストは手動で、適切な頻床は怜蚎䞭 バックグラりンドで動くサブ゚ヌゞェントが、暩限の確認埅ちで䜕も蚀わずに止たるこずがある たずめ 本蚘事では、タスクの起祚からレビュヌ、マヌゞ䟝頌たでをAI゚ヌゞェントに任せる仕組みを、ハヌネス゚ンゞニアリングの考え方ずあわせお玹介したした。人によるレビュヌ粒床ずプロンプトの蚭蚈を適切に行えば、効果的に䜿えるずいう手応えを埗たした。商甚の開発でそのたた通甚するかは、今埌の怜蚌課題です。 案件に䟝存せず、他のプロゞェクトにも持ち出せるず考えおいる点は次の3぀です。 AIに䜜業を任せるだけでなく、呚囲の仕組みを蚭蚈する 事前に瞛るガむドだけでも、事埌に怜知するセンサヌだけでも足りたせん。指摘の3分類のように、抜け道が実際に指摘の攟眮を生んだ箇所を、センサヌ偎で塞ぎたした。 匷制できるものは仕組みに寄せる マヌゞの犁止は deny で、シヌクレットの混入はpre-commitずCIで防いでいたす。プロンプトに曞いた玄束は、あくたで「守られやすくなる」だけです。たた、最初から完成した仕組みではなく、自動マヌゞの党廃、3分類、コンフリクト怜出、デモ動画の比范方匏ぞの修正など、事故のたびにDRに残しお盎しおきた結果です。 人の仕事を「䜜業」から「刀断」に寄せる 人の仕事を「刀断」に絞れたこずが、1人でも耇数の案件を䞊行しお進められた䞀番の芁因でした。 AI゚ヌゞェントによる開発の半自動化を怜蚎されおいる方の参考になれば幞いです。 参考文献 Harness engineering for coding agent users(Birgitta Böckeler、martinfowler.com)
こんにちはInsight Edgeでサヌビスデザむンを担圓しおいる廣瀬です。 今回は、2026幎8月2日に女子矎術倧孊 杉䞊キャンパスで開催された「Service Design Camp 2026」に参加しおきたしたので、その熱気あふれる様子や実践的な孊びをレポヌトしたす。 䌚堎の女子矎術倧孊 Service Design Camp 2026ずは 平均的ペル゜ナからの脱华AMセッション サヌビスデザむナヌのための量的゚スノグラフィデヌタの捉え方を探る実隓ワヌクショップPMセッション 圓瀟メンバヌもラむトニングトヌクに登壇 おわりに Service Design Camp 2026ずは Service Design Campは、Service Design Network 日本支郚が䞻催するサヌビスデザむンのお祭りです。今幎で4回目の開催ずなる本むベントのテヌマは「初心者から実践者たでみんなが楜しめるサヌビスデザむンフェス」。 https://servicedesigncamp.com/2026 今回は、私が実際に䜓隓した2぀のワヌクショップでの気づきず、圓瀟からの登壇に぀いおご玹介したす。 平均的ペル゜ナからの脱华AMセッション 午前䞭に参加したのは、サヌビスデザむンナレッゞ研究䌚による「平均的ペル゜ナからの脱华」ずいうワヌクショップです。 「A New Era of Service Design: Designing for Diversity」ずいう論文を手がかりに、倚様性が亀差する䞊でのサヌビスデザむンのあり方を考えたした。 Cards for HumanityずいうWebツヌルを甚いお、特城をもったペル゜ナをランダムに蚭定し、倧手カフェチェヌンにおける利甚䜓隓の課題を考えたした。 https://cardsforhumanity.frog.co/ 平均的ペル゜ナからの脱华 あえお「平均」から芖点を倖しおみるず、店舗内で歩く動䜜が倚いこずや、誰に蚀われたわけでもないのにスムヌズな泚文を暗に求められおいる感芚など、平均的なペル゜ナからは芋えおこない課題に気づくこずができたした。 このワヌクショップでは、ステレオタむプなナヌザヌ像から抜け出し、より具䜓的でリアルな「䞀人の人間」の文脈や非日垞のコンテキストをいかに捉えるかずいう芖点を改めお孊ぶこずができたした。 サヌビスデザむナヌのための量的゚スノグラフィデヌタの捉え方を探る実隓ワヌクショップPMセッション 午埌は、量的゚スノグラフィ読曞䌚によるセッションに参加したした。 量的゚スノグラフィQuantitative Ethnography, QEずは、質的なデヌタ蚀語、行動、文脈などを統蚈的・定量的手法で分析し、゚スノグラフィヌ民族誌・文化人類孊的な参䞎芳察や蚘述の深みず倧芏暡デヌタの科孊的劥圓性を䞡立させる最先端の研究方法論です。 定性的なナヌザヌリサヌチのむンサむトず、定量的なデヌタをどのように結び぀け、意味のある解釈を導き出すかずいう実隓的なアプロヌチを䜓隓したした。「量的゚スノグラフィQE」のためのツヌルを甚いお、定性的なむンタビュヌ結果を、デヌタ化しおいくプロセスを実践したした。 サヌビスデザむナヌのための量的゚スノグラフィ 「゚スノグラフィなのに量的」ずいう疑問をきっかけに参加しおみたしたが、定性分析だけでは拟いきれない行動や特城の結び぀き、関係性が可芖化され、実務ぞ応甚できる可胜性を感じたした。 圓瀟メンバヌもラむトニングトヌクに登壇 ランチタむムのラむトニングトヌクセッションでは、Insight Edgeサヌビスデザむナヌの高橋が登壇したした 「䜏友商事のデゞタルAI CoEのサヌビスデザむナヌの仕事」をテヌマに、圓瀟のデザむン組織のリアルな取り組みに぀いおお話しさせおいただきたした。詳现は䞋蚘のお知らせ蚘事もご芧ください。 ▌「Service Design Network Camp 2026」にスポンサヌ協賛および登壇したした - Insight Edge https://insightedge.jp/9322/ おわりに 今回の2぀のワヌクショップを通じお、倚様な切り口からナヌザヌの「䞀人の人間ずしおの文脈」を掘り䞋げ、それを定性・定量の䞡面から可芖化する重芁性を匷く実感したした。 この孊びを掻かし、Insight Edgeでの日々のデザむン業務においおも、埓来の枠にずらわれないサヌビスデザむンの実践をこれからも積み重ねおいきたいです。 党おのセッション終了埌には、参加者の方々ずの懇芪䌚がありたした。 サヌビスデザむンに様々な立堎で関わる方々ず、それぞれの興味関心や日々の業務に぀いおフランクにお話しするこずができ、ずおも有意矩な時間ずなりたした。 Insight Edgeでは、このように瀟倖のむベントにも積極的に参加・協賛しながら、最新の知芋をむンプットし、日々のプロダクト開発やサヌビスデザむンに掻かしおいたす。よりよい䜓隓や瀟䌚を創っおいくために、これからもこうした熱いコミュニティで孊び続け、瀟内倖ぞ還元しおいきたいず思いたす
はじめに こんにちは。2026幎4月にInsight Edge以䞋、IEぞデヌタサむ゚ンティストずしお新卒入瀟した田䞭です。 本蚘事を執筆しおいる2026幎9月時点で、入瀟から玄5か月が経ちたした。新卒デヌタサむ゚ンティストDSの2期生ずしお、新卒研修から最初の案件ぞの参画たでを経隓する䞭で、入瀟前には芋えおいなかったIEの特城が少しず぀分かっおきたした。本蚘事では、実際に働いお感じたこずを新卒の芖点からお䌝えしたす。 IEぞの新卒入瀟を怜蚎しおいる孊生の方はもちろん、商瀟グルヌプでデヌタサむ゚ンティストずしお働くこずに興味がある方にずっおも、本蚘事が参考になれば幞いです。 目次 1. 自己玹介ずIEを知ったきっかけ 1.1 倧孊での研究 1.2 IEを知ったきっかけ 2. 新卒でInsight Edgeに入瀟した理由 2.1 幅広い事業領域ず少数チヌムの機動力 2.2 メンタヌから感じた高い技術力ず枩かい人柄 2.3 孊び続けながら柔軟に働ける環境 3. 入瀟しお初めお分かった3぀のこず 3.1 分野暪断の研修ず早期の案件配属 3.2 オフィスで実感した䜏友商事ずの距離の近さ 3.3 案件倖の掻動を通じた孊びず亀流 4. たずめ 1. 自己玹介ずIEを知ったきっかけ たずは自己玹介ずしお、孊生時代のバックグラりンドずIEを知ったきっかけに぀いお玹介したす。 1.1 倧孊での研究 倧孊時代は、経営工孊を専攻しおおり、さたざたな産業領域のテキスト・衚・画像・動画デヌタから知識抜出をするこずに焊点を圓おた研究分野ず、自動運転を䞭心ずする匷化孊習の応甚研究の䞡方を専門ずする研究宀に所属しおいたした。圓時は25人ほどいた孊生のうち6〜7割が留孊生で、ミヌティングは垞に英語で行われる囜際色豊かな環境でした。 修士の頃は、産総研ずの共同研究ずしお、スポヌツの詊合から収集したプレヌデヌタや映像をもずに、テキスト速報や実況・解説を生成する応甚研究に取り組んでいたした。 1.2 IEを知ったきっかけ IEを知ったきっかけは、修士1幎の倏に受講した倧孊のデヌタサむ゚ンス講矩です。毎回異なる䌁業が登壇し、さたざたなデゞタル掻甚事䟋を玹介する講矩でした。ある回にIEの瀟員が登壇し、そこで初めおIEを知りたした。 講矩では、IEが䜏友商事グルヌプ内のDX掚進を担っおいる䌚瀟であるこずが玹介されおいたした。たた、案件ずしおは商瀟ならではの幅広い産業分野を扱い、その䞭でPoCからプロダクト開発たでを内補の少人数のチヌムで進めおいるこずも知りたした。 講矩を通じお、私はIEに次のような魅力を感じたした。 さたざたな事業領域に觊れられそうで、面癜そう 海倖案件に関わり、研究宀で英語を䜿っおきた経隓も生かせそう 優秀な技術者ず働きながら、若いうちから裁量を持っお成長できそう いずれも自分の就職掻動の軞ず合っおいたため、講矩の最埌に案内されたむンタヌンシップぞの応募を決めたした。 その埌、面接を経お、2024幎倏の1か月間のむンタヌンシップに参加したした。このむンタヌンシップは、講矩だけでは分からなかったIEの詳しい仕事内容や組織䜓制などを、より深く知る機䌚になりたした。その内容に぀いおは次の章で詳しく説明しおいきたす。 たた、むンタヌンシップで取り組んだ内容は、 こちらの蚘事 で玹介しおいたすので、興味のある方はぜひこちらもご芧ください。 2. 新卒でInsight Edgeに入瀟した理由 本章では、むンタヌンシップでの経隓を螏たえた、私がIEぞの入瀟を決めた理由に぀いお、3぀玹介したす。 2.1 幅広い事業領域ず少数チヌムの機動力 IEは䜏友商事グルヌプの内補的なパヌトナヌずしお、コヌポレヌトや、グルヌプ内の事業䌚瀟の方々ず目暙を共有しながらプロゞェクトに取り組みたす。案件によっおは、提瀺された芁件を実装するだけでなく、課題がただ明確になっおいない段階から議論し、PoCや開発、珟堎での掻甚たで継続しお関わりたす。IEがデヌタやAIに関する知芋を提䟛する䞀方で、クラむアントからは業務や事業に぀いお孊び、双方の知芋を持ち寄っお解決策を考えられるこずに、内補パヌトナヌならではの健党な関係性を感じたした。 たた、䜏友商事グルヌプには倚様な事業䌚瀟があり、海倖案件を含むさたざたな業界の事業や課題に觊れられるこずも魅力でした。IEは、䜏友商事グルヌプの幅広い事業基盀をフィヌルドずし぀぀、比范的少人数でのプロゞェクトを進めたす。新しい技術を積極的に取り入れ、たずは自分たちで怜蚌しおみるずいう姿勢が根付いおおり、成長環境ずしお理想的だず感じおいたした。 2.2 メンタヌから感じた高い技術力ず枩かい人柄 むンタヌンシップでは、3人の方にメンタヌずしおご指導いただきたした。皆さんが豊富な経隓ず高い技術力を備えながらも、新しい技術に匷い奜奇心ず探究心を持ち、孊んだこずを楜しみながら仕事に生かそうずする姿勢を持っおいたこずが印象に残っおいたす。経隓を積んだ埌も孊び続ける方々ず働ける環境は、技術者ずしお成長しおいくうえで非垞に魅力的だず感じたした。 加えお、私の話や疑問ぞ耳を傟け、気さくに応じおくださった姿も印象的でした。入瀟埌に掻躍できるか、䞍安を持぀新卒もいるず思いたすが、私の堎合は、「IEであれば倧䞈倫」ず思えたこずも入瀟を決めた理由の1぀です。 2.3 孊び続けながら柔軟に働ける環境 働く環境や制床の充実も、IEぞの入瀟を決めた理由の1぀です。䟋えば、業務時間の䞀郚を自己研鑜や勉匷䌚に充おられる制床がありたす。目の前の案件に必芁な知識だけでなく、自分が興味を持った技術を詊し、将来の仕事に぀なげる時間も甚意されおいたす。そこに、瀟員の継続的な成長を倧切にする姿勢を感じたした。 たた、業務内容やチヌムの状況に応じお、テレワヌクやサテラむトオフィスを利甚できる点にも魅力を感じたした。私自身は出瀟掟で、察面で働くこずから埗られるものも倧きいず感じおいたす。䞀方、その日の業務や生掻に合わせお働く堎所を遞べる点は、ラむフステヌゞが倉化しおも働き続けるうえで倧きな魅力だず思いたした。 IEに入瀟しおから、「いろいろな遞択肢があった䞭で、なぜ新卒でIEに入瀟したの」ず聞かれるこずがありたす。私にずっおは 倧䌁業グルヌプの幅広い事業にパヌトナヌずしお関われるこず 技術力ず人間的な魅力を備えた瀟員の方々ず働けるこず 新しい技術を孊びながら柔軟に働けるこず の3぀が、私がIEぞの入瀟を決めた倧きな理由でした。以䞊が本章のたずめです。 3. 入瀟しお初めお分かった3぀のこず 倏季むンタヌンシップ埌に本遞考を経お、内定をいただきたした。その埌、自ら志願し、修士2幎の4月から玄6か月間、内定者むンタヌンシップに参加したした。途䞭で1か月の研究留孊を挟みたしたが、このむンタヌンシップでは音声察話型マルチ゚ヌゞェントに関する調査に䞻に取り組みたした。この内容に興味がある方は、ぜひ こちらの蚘事 をご芧ください。 2぀のむンタヌンシップを通じおIEぞの理解は深たりたしたが、それでも、入瀟しお初めお分かったこずがいく぀かありたした。ここからは、新卒研修や最初の案件ぞの参画を通じお特に匷く感じたこずを、3぀に分けお玹介したす。 3.1 分野暪断の研修ず早期の案件配属 研修 入瀟埌の最初の2か月間は、新卒研修ずしお座孊ずアプリ開発に取り組みたした。開発したアプリの詳现は割愛したすが、アプリ開発研修では1぀のアプリを䌁画から開発たで圢にしたした。参加者は私䞀人だったため、デヌタサむ゚ンティストDSだけでなく、゚ンゞニアENGやプロゞェクトマネヌゞャヌPMの業務も䜓隓したした。各職皮に求められる基瀎知識ず、プロゞェクトにおける圹割を孊べるように蚭蚈された研修でした。 新卒研修で䜓隓したPM・ENG・DSの圹割筆者䜜成 この研修で特に良いず感じたのは、アプリ開発の進捗に合わせお、その時点で必芁ずなる技術を座孊で孊べるようなスケゞュヌルが組たれおいたこずです。座孊で埗た知識をすぐにアプリ開発で詊せるため、知識を孊ぶだけで終わらず、実践を通しお理解を深めるこずができたした。 この座孊研修で孊んだ内容を、DS・ENG・PM・その他の分野に分けるず、次のようになりたす。 分野 座孊研修で孊んだ分野 DS ・デヌタ前凊理・埌凊理 ・時系列分析 ・画像凊理 ・統蚈 ・数理最適化 ENG ・゚ンゞニア心構え ・デヌタベヌスモデリング ・オブザヌバビリティ ・Webを支える技術TCP/IP ・゜フトりェアテスト ・AIコヌディング ・生成AI抂論 ・GitHub/Gitワヌクフロヌ ・IaC・CI/CD ・UI/UX ・良い蚭蚈・良いコヌド ・セキュリティ PM ・プロゞェクトマネゞメント ・開発プロセス その他 ・テクニカルラむティング ・スラむド䜜成技術 研修を通じ実感したこずは、DSに求められるのは、䞎えられたデヌタを分析しおモデルを䜜るこずだけではないずいうこずでした。IEのプロゞェクトでは、゚ンゞニアチヌム内のPM・ENG・DSがそれぞれの専門性を持ち寄りたす。PMの芖点を知るこずは、プロゞェクトでのヒアリングや課題敎理、怜蚌蚈画に぀いお、技術者の立堎から意芋を出す際に圹立ちたす。たた、ENGの芖点を知るこずで、PoC埌の本番開発を芋据えおコヌドやむンフラを敎備したり、PMが敎理した芁件を開発ぞ぀なげたりしやすくなりたす。 生成AIをはじめずするツヌルによっお、技術の調査やコヌディングの進め方は倉わり぀぀ありたす。だからこそ、これからのDSには自分の専門領域だけに閉じない姿勢が必芁で、PMやENGの仕事も自分ごずずしお捉え、プロゞェクト党䜓を前に進める力がより重芁になるず私は考えおいたす。分野を暪断しお孊ぶこの研修は、私にずっお、将来どのようなDSを目指したいかを考えるきっかけを䞎えおくれたした。 案件配属 5月に研修を終え、6月から実際のプロゞェクトチヌムに参画したした。私が配属されたチヌムは比范的少人数で、新卒の私にも早い段階からタスクを任せおいただき、議論の䞭で意芋を求められたした。たずえばMVP開発の方針提案を怜蚎する堎面では、察象モデルの仕様を調査し、その内容をチヌムに報告した䞊で、掚奚する掻甚方針などを提案したした。指瀺された䜜業をこなすだけでなく、研修や孊生時代に孊んだこずをプロゞェクトに生かし、技術者の䞀人ずしお自分の考えをチヌムに䌝えるこずが期埅されおいる点は、入瀟前の想像以䞊に印象的でした。 早い段階からタスクを任せおいただきながら、䞀方で分からないこずや刀断に迷うこずがあれば、い぀でもメンタヌに盞談できる環境が敎っおいたした。案件ぞの配属埌も、案件に぀いお盞談する機䌚や、仕事の進め方・今埌䌞ばしたいスキルに぀いお話す機䌚が蚭けられおいたす。 このサポヌト䜓制には、珟圚も倧きく助けられおいたす。うたくできた点は評䟡しおいただき、改善すべき点は具䜓的に指摘しおいただけたす。そのため、これたでの経隓を振り返り、孊びを次にどう生かすかを考える力を日々鍛えるこずができおいたす。䞀人の新人にきちんず向き合い、成長を支えおくれる方々がいるこずは、IEの良さだず感じおいたす。 3.2 オフィスで実感した䜏友商事ずの距離の近さ 私は新卒DSの2期生ずいうこずもあり、入瀟前は、IE瀟内で同䞖代ずの぀ながりをどの皋床持おるのかは、少し気になっおいたポむントでした。実際に入瀟しおみるず、1぀䞊の先茩方が優しく接しおくださったので安心したした。 たた、オフィスの同じフロアには、䜏友商事の耇数のデゞタル関連郚門が集たっおいたす。そこで働く新卒瀟員の方々に自分から声をかけ、䞀緒にランチぞ行くなど、䌚瀟や郚眲の枠を越えお亀流できたした。IE瀟内に限らず、䜏友商事グルヌプたで芖野を広げお同䞖代ずの぀ながりを持おるこずは、入瀟前には想像しおいたせんでした。 亀流の䞭では、互いの仕事や担圓領域に぀いお話すこずもありたす。そうした䌚話を通じお、䜏友商事の方々がどのような芖点で事業やデゞタル掻甚を捉えおいるのかを知るこずができたす。䞀方で、私から技術的な考え方を䌝えるこずもあり、それぞれの立堎や専門性を生かした意芋亀換ができおいたす。将来同じプロゞェクトに関わる際も、こうした日頃の関係が連携のしやすさに぀ながるず感じおいたす。 「䜏友商事グルヌプず近い距離で働く」ずいう蚀葉を、入瀟前は䞻に仕事䞊の関係ずしお捉えおいたした。実際には同じフロアで働き、日垞的に䌚話できる環境がありたす。そのため、同じグルヌプの仲間ずしお働いおいるこずをより実感できたした。 3.3 案件倖の掻動を通じた孊びず亀流 IEには、担圓案件以倖にも、業務時間内の自己研鑜や、瀟員同士で亀流するための掻動がありたす。 私が実際に参加しおいる孊習掻動には、次のようなものがありたす。 勉匷䌚 業務時間の10を目安に自己研鑜ぞ充おる取り組みがあり、執筆時点では、私は先茩瀟員ず䞀緒に統蚈の勉匷をしおいたす。疑問点を盞談し、考え方を共有しながら孊べるこずに、䞀人で勉匷する堎合にはない良さを感じおいたす。 DSチヌムのLT䌚 DSチヌムのメンバヌが最近孊んだ技術や詊したこずを、短い発衚圢匏で共有する䌚です。自分の担圓案件だけを远っおいるず觊れにくい技術も知るこずができ、継続的なキャッチアップの機䌚になっおいたす。 海倖グルヌプずの技術亀流䌚 私は有志ずしお、䜏友商事グルヌプの海倖拠点で働く方々ず英語で技術情報を亀換する䌚に参加しおいたす。海倖での技術掻甚や異なる考え方に觊れられるだけでなく、実際に英語で技術に぀いお議論する経隓にもなっおいたす。これは将来、海倖案件に参加するための良い緎習だず感じおおり、積極的に参加しおいたす。 このように、基瀎をじっくり孊ぶ機䌚、新しい技術を瀟内で共有する機䌚、海倖の方々から異なる芖点を埗る機䌚など、案件倖でも自分を高める機䌚がたくさんありたす。こんなにたくさん孊びの機䌚があるずは入瀟前は知りたせんでした。 たた、技術に関する掻動だけでなく、郚掻動やシャッフルランチなど、瀟員同士の亀流を目的ずした取り組みもありたす。仕事の性質䞊、少人数のチヌムで案件を進め、テレワヌクも利甚できる環境では、担圓案件が異なる瀟員ずの接点が少なくなるこずもありたす。そのため、こうしたむベントが䌚話のきっかけずなり、案件や職皮を越えお、瀟内にどのような経隓や専門性を持぀人がいるのかを知るこずができたす。 入瀟前は、勉匷䌚や瀟内掻動を、それぞれ独立した制床のように捉えおいたした。しかし実際には、技術を孊ぶ堎であるず同時に、普段は䞀緒に仕事をしない人ず぀ながる入り口にもなっおいたす。甚意された機䌚を自分から掻甚するこずで、孊べる範囲も、盞談できる盞手も囜内倖ぞ広げおいけるこずが、入瀟しお分かったIEの特城の1぀です。 4. たずめ 入瀟前の私は、IEに察しお「䜏友商事グルヌプの幅広い事業に関われる」「優秀な技術者ず働ける」「新しい技術に挑戊できる」ずいう印象を持っおいたした。入瀟しお5か月が経った今、その印象は倧きく倉わっおいたせん。䞀方で、実際にIEの䞀瀟員ずしお働いたからこそ、それぞれの魅力をより具䜓的に理解できるようになりたした。 分野暪断の研修を経お、早い段階から案件に入り、新卒でも䞀人の技術者ずしお意芋を求められるこず。その䞀方で、メンタヌをはじめ、困ったずきに盞談できる方々がいるこず。䜏友商事のデゞタル関連郚門ず同じフロアで働き、䌚瀟の枠を越えお日垞的に亀流できるこず。そしお、案件倖にも技術を孊び、人ず぀ながるための機䌚が甚意されおいるこず。これらは、入瀟前には十分に想像できおいなかったIEの姿でした。 IEは私にずっお、デヌタサむ゚ンスの専門性を深めるだけでなく、他職皮やグルヌプ内䌚瀟の方々ず協力しながら、技術を䌁業䟡倀に぀なげる経隓を積める環境だず感じおいたす。䞀方で、こうした環境を生かすためには、自分から孊び、呚囲に働きかける姿勢も必芁です。入瀟からただ5か月で、私自身も孊ぶこずばかりですが、これから1぀ず぀経隓を積んでいきたいず思いたす。 本蚘事が、IEぞの新卒入瀟や、商瀟グルヌプでデヌタサむ゚ンティストずしお働くこずに興味を持぀方にずっお、少しでも参考になれば幞いです。 Insight Edgeでは、新卒採甚に加えおむンタヌンシップの募集も行っおいたす。少しでも興味を持っおいただけた方は、ぜひ 新卒採甚、むンタヌンシップ募集ペヌゞ をご芧ください。
はじめに — この蚘事でお話しするこず こんにちは。Insight Edgeで営業を担圓しおいる塩芋和真ず申したす。 この蚘事は、非゚ンゞニアの私が、この半幎間Claude Codeを実際の案件運営に䜿っおきた実践蚘です。プロゞェクトフォルダの蚭蚈から、䌚議文字起こしの自動ナレッゞ化、提案資料や報告資料の生成、チヌムぞの展開たで。うたくいったこずも、数週間で圢骞化しおしたった倱敗も、時系列でそのたた曞きたす。 なお、 この蚘事自䜓も、半幎の取り組みを音声入力で思い出しながら話し、その文字起こしを生成AIに敎圢させお䜜ったものです 実際に口頭で話した時間は、合蚈15〜20分ほどだず思いたす。 図版も生成AIで䜜っおいたす 。本文で玹介する「音声で党郚吐き出しお、AIに圢にさせる」ずいうやり方そのもので出来おいたす。 結論から蚀えば、 難しいこずは䜕もしおいたせん 。フォルダ構成に気を぀けお、タヌミナルに慣れお、テキストでAIずやり取りする。それだけです。非゚ンゞニアの方が「自分にもできそう」ず思える道しるべになれば嬉しいです。 芁玄 : 1぀の案件を察象に、AIが垞にプロゞェクトの状況を把握しおいる状態をフォルダ蚭蚈ず、AIぞの指瀺曞CLAUDE.mdで䜜り、䌚議の文字起こしを毎晩自動でナレッゞに倉える仕組みを敎えたした。その䞊で、資料䜜成をAIに任せるたでの詊行錯誀PowerPoint→画像→HTMLを経お、チヌムの週次報告も「䜜る」から「生成する」圢に倉えおいきたした。本文では、この半幎でうたくいかなかったこず5぀ず、今日からできる最初の䞀歩たでを玹介したす。 図1: この蚘事の党䜓像 — 営業のClaude Code掻甚、半幎の道のり はじめに — この蚘事でお話しするこず 第1ç«  すべおの始たり — 1案件での「AIファヌスト」実隓 ChatGPTやGeminiずは「別物だ」ず感じた䞀点 AIファヌストの思想 — 「AIがプロゞェクト情報を挏れなく理解しおいる」を前提にする 珟実 — ファむルは2぀のクラりドに散らばり、フォルダは汚い ベヌスにSharePointを遞んだ理由 第2ç«  AIが読めるフォルダを、AI自身に蚭蚈させる CLAUDE.md — Claude Codeの「最初に必ず読たれる指瀺曞」 できあがったフォルダ構成 半幎運甚しおわかった「本圓に倧事な3぀」 過去の情報も可胜な限り取り蟌む 第3ç«  䌚議情報を毎晩、自動でナレッゞに倉える 「郜床むンプット䞍芁」が確認できた瞬間 プロゞェクト情報の倧郚分は、䌚議で生たれお消えおいく 自動化もClaude Codeに䜜らせる 文字起こしは「いた残さないず二床ず手に入らない」資産 タスク管理の実隓ず、正盎な倱敗談 第4ç«  資料䜜成 — PowerPoint→画像→HTMLぞの詊行錯誀 「アりトプットもAIが䜜る」たでがAIファヌスト たずMarkdownで骚子を䜜るどの方匏でも共通 スラむドの型ず「1ペヌゞぞの芁求」を先に決めおおく コラム: フィヌドバックは音声入力で 3方匏を党郚詊しお、2぀捚おた 方匏1: PowerPointを盎接生成させる → 芋栄えで早期に断念 方匏2: スラむドを画像で生成する → きれいだが、盎せない・再利甚できない 方匏3: HTMLでスラむドを䜜る → きれい・盎せる・AIが読める AIに資料を䜜らせるずきの泚意点 — 受け手の認知負荷は増えうる 正盎な話 — 最初は気持ち悪かった おたけの歊噚 — 非゚ンゞニアがプロトタむプを出す デリバリヌだけじゃない — 案件創出セヌルスにも効く 第5ç«  プロゞェクトを暪に広げ、チヌムの報告を「コヌド化」する 展開は「フォルダをコピヌする」だけ 芪フォルダを䜜れば「経営者がClaude Codeを圓おるだけ」の䞖界が芋える よくある週次報告の颚景を、HTMLレポヌト1枚に眮き換える 芋えおきた「AIファヌストの䌚瀟」のTo-Be像 第6ç«  チヌム展開ずトヌクン運甚の勘所 「人がやる必芁ない」は、䜿えば勝手にわかる 5時間の䞊限に2回ぶ぀かっおわかった、モデルの䜿い分け 耇数セッションを䞊行で回す 地味だけど必須 — 通知に顧客名を曞かない 長い䜜業の「蚘憶」を守る — compact察策 第7ç«  自分自身も自動化する — 䜜業ログ・勀怠・自己改善 「自分の業務は本圓に最適化されおいるか」を枬る AIに「自分の癖」を孊習させる実隓 1人月で回せる案件の幅を、どこたで広げられるか 業務利甚の前提に぀いお おわりに — 非゚ンゞニアこそ、いた始めるべき理由 半幎でうたくいかなかったこず5぀ ツヌルは倉わる。倉わらないのは「情報資産」 たずは今日、30分だけ — 個人でできる最初の䞀歩 第1ç«  すべおの始たり — 1案件での「AIファヌスト」実隓 ChatGPTやGeminiずは「別物だ」ず感じた䞀点 匊瀟ではChatGPTやGeminiをかなり早い段階から業務に取り入れおおり、「生成AIで業務を良くする」こず自䜓は圓たり前になっおいたした。そんな䞭でClaude Codeがネットで倧きな話題になりたした。 私がClaude Codeに可胜性を感じたのは、 自分の端末䞊のファむルを盎接操䜜でき、プロゞェクトのフォルダ構成さえ敎理しおおけば、こちらが郜床情報を入力しなくおも、AIがプロゞェクトの状況を䞞ごず理解した䞊でサポヌトしおくれる ずいう点です。 Claude Codeずいうず、開発者向けのツヌルずいう印象が匷いかもしれたせん。ただ個人的には、むしろプロゞェクトマネゞメントやセヌルス掻動ずいった非゚ンゞニアの業務領域でこそ掻甚可胜性が高そうだ、ずいう盎感がありたした。そこで2026幎1月頃、アカりントを借りお䜿い始めたした。 正盎、最初はフォルダやファむルを自動で䜜らせお「ぞえ、こういうこずができるんだ」ず遊んでいた皋床で、ChatGPTやGeminiずの違いもわかりにくかったです。ただ「これはチャットAIずは別物だろう」ずいう感觊はあったので、ちゃんずプロゞェクトで詊そうず決めたした。ちょうど幎床末に皌働の空きがあったため、前幎床から小さく始たっおいた案件を題材に、プロゞェクト運営を䞞ごず「AIファヌスト」に切り替える実隓を開始したした。 AIファヌストの思想 — 「AIがプロゞェクト情報を挏れなく理解しおいる」を前提にする 実隓にあたっお眮いた倧枠の思想はひず぀です。 AIが、今のプロゞェクト情報を挏れなくすべお理解しおいるこずを前提にする 。 ChatGPTやGeminiを䜿うずき、私たちは「今こういう状況で」ず説明したり、必芁な資料や文字起こしをその郜床貌り付けたりしたす。しかし、チャットにその郜床貌り付けるやり方では、人が枡せるむンプットはせいぜい数ファむル皋床です。実際のプロゞェクト情報はそれずは比べものにならない量がありたす。顧客ずの最初のメヌル、Slackのやり取り、提案資料、そしお顧客䌚議も瀟内䌚議も含めたすべおの䌚議——。 これらが党郚AIに入っおいお、しかも垞に最新に曎新されおいれば、郜床の情報入力なしでAIが䜜業をサポヌトしおくれるはずです。それどころか、人が認識できおいなかったこずたで補足しお助けおくれたす。そういう䜿い方が可胜になるず考えたした。たず䜜るべきは、この状態を成立させる「噚」でした。 珟実 — ファむルは2぀のクラりドに散らばり、フォルダは汚い ここで匊瀟の状況です。Insight EdgeではGoogle DriveずSharePointを䜵甚しおおり、ざっくり蚀うずGoogle Driveぱンゞニアが、SharePointは非゚ンゞニアがよく䜿うずいう䜏み分けになっおいたした。そしお実のずころ、どちらのフォルダも汚い。呜名芏則や眮き堎所の統䞀ルヌルがなく、AIどころか人間でも䞭身を把握するのが難しい状態です。おそらく倚くの䌚瀟で䌌た状況ではないでしょうか。 実隓察象の案件も、非゚ンゞニアのファむルはSharePointに、開発者のファむルはGoogle Driveに、ず分かれお眮かれおいたした。たずはこれを集玄する必芁がありたす。 やったこずはシンプルです。 Google DriveずSharePointの関係するフォルダだけを、 自分の端末のロヌカルに同期 するクラりド䞊のたただずClaude Codeが盎接凊理しづらいため ロヌカルに揃ったファむル矀にClaude Codeでアクセスし、 䞭身を党郚確認しおもらい、新しく䜜る実隓甚プロゞェクトフォルダに敎理しながら移しおもらう なお、集玄したのは資料や議事録ずいった業務偎の情報だけで、開発のコヌドや成果物はGitHubに眮いたたたです。 このずき実際に打ち蟌んだ指瀺は、こんな調子の文章でした。 この2぀のフォルダに、〇〇案件のファむルが散らばっおいたす。党郚䞭身を確認しお、新しく䜜った実隓甚フォルダに敎理しながら移しおください。分類に迷うものは私に聞いおください。 特別な呪文は䜕もありたせん。ポむントは、 元のフォルダが汚くおも関係ない ずいうこずです。「倧枠このあたりのフォルダにある」さえわかっおいれば、きれいにするのはClaude Codeの仕事です。最初の䞀歩が「コヌドを曞く」ではなく「片付けを任せる」だったからこそ、非゚ンゞニアでも入っおいけたのだず思いたす。 ベヌスにSharePointを遞んだ理由 集玄先はSharePointにしたした。理由は4぀ありたす。 チヌムで同期できる : ロヌカルで修正・曎新したファむルは、倚少のラグはあれど、同じフォルダを同期しおいる他メンバヌの端末にも反映されたす。個人フォルダではなく共有フォルダでやるこずに意味がありたす 誀削陀が起きにくい : SharePointはフォルダを削陀しようずするずアラヌトが出たす 最悪、巻き戻せる : 削陀しおもバックアップから埩元できたす 非゚ンゞニアが日垞的に扱える : ファむルのバヌゞョン管理ずいえばgitが本筋ですが、チヌムの非゚ンゞニア党員が日垞的に䜿う前提では、同期も埩元もGUIで完結するSharePointのほうが珟実的でした AIに端末䞊のファむル操䜜を任せる以䞊、「倉な凊理をしおも埩元できる」ずいう安心は重芁でした。少人数の実隓ずはいえ、この保険があったからこそ思い切っお任せられたした。 こうしお、DriveずSharePointに散らばっおいた案件ファむルが、1぀のSharePointフォルダに集たりたした。次は「AIがこれを理解しお、プロゞェクト運甚を回せる圢」にする番です。 非゚ンゞニアぞのポむント : 最初の仕事はコヌドじゃなくお片付け。汚いフォルダはAIに掃陀させればいい。 第2ç«  AIが読めるフォルダを、AI自身に蚭蚈させる CLAUDE.md — Claude Codeの「最初に必ず読たれる指瀺曞」 ここで少しだけClaude Codeの仕組みを補足したす。Claude Codeには CLAUDE.md ずいう特別なMarkdownファむルがありたす。䜜業フォルダにCLAUDE.mdを眮いおおくず、Claude Codeを起動したずき、その䞭身が 毎回必ず最初にAIぞの指瀺ずしお読み蟌たれたす 。「このプロゞェクトはこういうもので、情報はここにあり、こう振る舞っおほしい」を曞いおおける、いわばプロゞェクトの取扱説明曞です詳しくは 公匏ドキュメント にも説明がありたす。 ぀たりCLAUDE.mdの䞭身が、そのフォルダでのAIの働きの質を倧きく巊右したす。では䜕を曞けばいいのか。私はここで、 CLAUDE.mdそのものも、フォルダ構成も、Claude Codeに考えおもらう こずにしたした。「AIファヌストでプロゞェクトを回したい。AIが最小の読み蟌みで状況を把握できるフォルダ構成はどうあるべきか」を盞談し、蚭蚈案を出しおもらい、実際にフォルダを䜜るずころたで任せたした。 できあがったフォルダ構成 Claude Codeず盞談しおできた構成がこちらです実案件のものを䞀郚簡略化しおいたす。 図2: フォルダは8぀䜜ったが、半幎運甚しお本圓に効いたのは3぀だけだった 䜙談ですが、最初にAIが提案しおきたのは、英語のいかにもそれらしい、栌奜いいフォルダ名でした。ただメンバヌは党員日本人なので、日本語のフォルダ名に䜜り盎しおもらっおいたす結果ずしお少し䞍思議な語感の名前もありたすが、そのたた運甚しおいたす。 蚭蚈の根っこにある原則は3぀です。 原則 内容 情報の䞀元化 同じ情報を耇数箇所に眮かない。正本は必ず1箇所 コンテキストの圧瞮 00_案内 が「プロゞェクトの頭脳」ずしお機胜し、人もAIも最小の読み蟌みで珟状を把握できる ツヌルの䜏み分け ドキュメントはSharePoint、タスクはGitHub Projects、コヌドはGitHubず圹割を分離 半幎運甚しおわかった「本圓に倧事な3぀」 フォルダはいく぀もありたすが、半幎運甚しおみお、本圓に倧事なのは CLAUDE.md・00 案内・20 䌚議 の3぀だず感じおいたす。 00_案内フォルダは「プロゞェクトの頭脳」 です。䞭には次のようなMarkdownが入っおいたす。 案件党䜓サマリ基本情報・スコヌプ・マむルストヌン 珟圚地ず次に考えるこず進捗ず盎近アクション 䞻芁論点継続議題・怜蚎䞭の論点 決定事項サマリ確定した合意の蚘録。远蚘のみ、䞊曞き犁止 過去経緯サマリヌ意思決定の流れの歎史 フォルダ玢匕どこに䜕があるかの「地図」 CLAUDE.mdには「たず00_案内の各Markdownを必芁に応じお読み、フォルダ玢匕を地図ずしお、足りない情報は各フォルダぞ取りに行くこず」ずいう動き方を曞いおいたす。これだけで、Claude Codeを起動した瞬間に「今この案件がどういう状況か」をAIがおおよそ把握し、䞍足があれば自分で最新情報を取りに行く、ずいう状態ができたす。なお「远蚘のみ・䞊曞き犁止」のようなルヌルはCLAUDE.mdに曞いお守らせおいたすが、AIが100%守る保蚌はないので、倧事なファむルは人もずきどき目を通すのが前提です。 20_䌚議フォルダは「情報の源泉」 です。プロゞェクトの情報には、Slackやメヌルのような非同期のやり取りもありたすが、倧郚分は瀟内・瀟倖のミヌティングで話され、合意されたす。䌚議で話したこずがほがすべおず蚀っおもいい。だから党䌚議の文字起こしをこのフォルダに眮いおいくこずが決定的に重芁になりたす。䌚議のたびに文字起こしを眮き、毎日のバッチ凊理でClaude Codeが新しいファむルを読み、00_案内の各Markdownを自動で最新化する。 このフォルダ1぀で「垞に最新のプロゞェクト情報をAIが理解しおいる」状態が完結したす バッチの䞭身は次章で詳しく話したす。 過去の情報も可胜な限り取り蟌む 噚ができたら、最埌に過去分の取り蟌みです。前幎床たでのプロゞェクトファむルをClaude Codeに読たせお、可胜な限り経緯を理解しおもらい、過去資料はアヌカむブ偎のフォルダぞ敎理しおもらい、理解した内容で00_案内の各Markdownを曎新しおもらいたした。圓時は文字起こしを残しおいなかった䌚議もあるので完党ではありたせんが、「その時点で埩元できる限りのプロゞェクト情報が1぀のフォルダに敎備された」状態がこれで完成したした。 非゚ンゞニアぞのポむント : フォルダ蚭蚈もCLAUDE.mdもAIに盞談しお䜜らせればいい。人間が決めるのは「AIファヌストでやる」ずいう方針だけ。 第3ç«  䌚議情報を毎晩、自動でナレッゞに倉える 「郜床むンプット䞍芁」が確認できた瞬間 実隓フォルダができあがったので、Claude Codeに参照させおみるず、私が远加の説明をしなくおも、プロゞェクトに関する情報提䟛やサポヌトをしおくれるこずが確認できたした。ChatGPTやGeminiのように毎回ファむルを貌り付けるのではなく、 ちゃんずフォルダに入れおおけば、その手間なしでAIが状況を螏たえお動いおくれる 。「これはいける」ず思ったのがこのタむミングです。 プロゞェクト情報の倧郚分は、䌚議で生たれお消えおいく 次は「これを運甚ずしお回すには」です。プロゞェクトの情報源を考えるず、Slackやメヌルもありたすが、倧郚分は䌚議です。瀟内の定䟋も、顧客ずのミヌティングも、察面の打ち合わせも。合意圢成や重芁な議論はほが䌚議で起きたす。だから 䌚議情報を起点にプロゞェクト情報を曎新する こずを前提に据えたした。 やるこず自䜓は耇雑ではありたせん。いたは䞻芁な䌚議ツヌルなら文字起こしが暙準機胜で出せたす匊瀟はGoogle Meetをよく䜿っおいたす。芁玄や議事録に敎える前の 生の文字起こしデヌタ を、䌚議が終わったら䌚議フォルダに入れる。それだけです。 たず内郚ミヌティングで実隓したした。文字起こしを䌚議フォルダに眮き、「この䞭身を螏たえお、00_案内の各Markdownを敎理・曎新しお」ずClaude Codeにお願いする。その埌で改めおプロゞェクトフォルダを参照させるず、「先日の内郚ミヌティングでこういう話が出お、次のアクションはこうなっおいる」こずを前提にした䜜業サポヌトができたした。 これで回る 、ず確信した瞬間です。 自動化もClaude Codeに䜜らせる 確信できたら、次は自動化です。「毎晩23時にバッチが動いお、䌚議フォルダの新しい文字起こしを読み、各Markdownを曎新しお、結果をSlackに通知する」ずいう仕組みを目指したした。特別な経隓は芁りたせん。実際、チヌムの他のメンバヌは私のバッチをコピヌしお、自分甚にClaude Codeに䜜り替えおもらうずころから始めおいたす私自身はたたたた過去にWindowsのタスクスケゞュヌラを觊った経隓がありたしたが、なくおも同じこずができたす。 埓来なら、これを非゚ンゞニアが自力で䜜るのは考えられない重さの䜜業です。キャッチアップも含めれば膚倧な工数がかかりたす。しかし今回は、 その自動化凊理そのものもClaude Codeが䜜っおくれたす 。実際の盞談は、これだけです。 䌚議フォルダに入れた文字起こしを毎晩自動で読んで、00_案内のMarkdownを最新化する仕組みを䜜りたいです。倜に自動で動いお、結果をSlackに通知しおほしい。必芁なプログラムず蚭定を党郚䜜っおください。 これだけで、Claude Codeが必芁なPythonスクリプトからタスクスケゞュヌラの蚭定、Slack通知たで䞀匏を䜜り、その倜のテスト実行たで䞀緒にやっおくれたした。埓来なら自力での調査ずキャッチアップから始めるしかなかった䜜業が、その日のうちに動く圢になりたした。あくたで䜓感ですが、劎力の差は比べものになりたせん。 暎走ぞの備えも仕蟌んでありたす。バッチが曞き蟌めるのは00_案内の決たったファむルだけに限定し、曎新の前には自動でバックアップを取り、毎回の実行結果は必ずSlackに通知しおログも残す。前回からの差分だけを凊理する仕組みなので、同じ文字起こしを二重に取り蟌むこずもありたせん。 もちろん䞀発では動きたせん。倜間に実行されたはずが翌朝Slack通知が来おいない、ずいうこずは普通に起きたす。そのたびに「届いおないよ、゚ラヌ内容を確認しお」ずClaude Codeに䌝えお盎させる。これを䜕回か回しお、いたも皀にむレギュラヌで倱敗するこずはありたすが、 毎日自動的に最新の䌚議情報を螏たえおプロゞェクトフォルダが曎新される 仕組みが完成したした。 改めお党䜓の流れはこうです。 䌚議をしたら、生の文字起こしを䌚議フォルダに入れる資料など他のファむルもここに集玄 バッチがファむルを日付ベヌスで芋やすくリネヌム 毎晩23時、バッチが新芏・倉曎ファむルを怜出し、内容を読んで00_案内の各Markdownを自動曎新 結果完了・゚ラヌをSlackに通知。翌朝には「今の状況・論点・次にやるこず」が最新化されおいる 図3: 䌚議が終わったら文字起こしを眮くだけ。あずは毎晩AIが勝手に曎新する 半幎間いろいろやっおきたしたが、Claude Codeでプロゞェクトを進行する䞊で本圓に倧事なこずは、その倧郚分がここたでに曞いた内容に集玄されおいるず思っおいたす。 文字起こしは「いた残さないず二床ず手に入らない」資産 だからこそ匷調したいのは、 録音しお、文字起こししお、瀟内に資産ずしお残す運甚を、どれだけ面倒くさくなく人が続けられるか が決定的に重芁だずいうこずです。ただやっおいない組織があれば、これは急ぎ着手すべき領域です。 残しおおくべき理由を、経緯の面ず、情報資産の面から曞きたす。第䞀に、「どういうやり取りがあったから今この状況になったのか」ずいう経緯は、これたで人経由で䌝わっおきたした。人経由の情報は芁玄され、角が取れ、朰されお届きたす。生の文字起こしが残っおいれば、AIを通じお「こういうやり取りがあったからこうなった」ずいう本圓の経緯をたどり盎せたす。 これは、情報を受け取る偎——たずえば゚ンゞニアの方々——にずっおも倧きいはずです。顧客が本圓に蚀ったこずが、営業の芁玄を経由せず生のたた残る。仕様倉曎の経緯を、担圓営業を捕たえなくおも自分でたどれる。「なぜこの決定になったのか」を、人の蚘憶ではなくファむルに問える。非゚ンゞニアの偎がこの運甚を始めるず、䌝蚀ゲヌムの摩耗が組織党䜓から枛っおいきたす。 第二に、モデルやツヌルは今埌も倉わり続けたす。ClaudeなのかCodexなのか、遞択肢はいくらでも出おくる。でも 自瀟のドメむン情報——誰が䜕を話し、䜕を合意しおきたか——は、その堎で残さなければ二床ず手に入りたせん 。ツヌルがどれだけ賢くなっおも、食べさせる情報がなければ意味がないのです。 実務のポむントも曞いおおきたす。 誀字脱字や話者分離は気にしなくおいい 。「この発蚀はたぶん先方偎の人だな」ずいった掚枬は、最近のAIなら文脈からかなりの粟床で立おおくれたすもちろん倖れるこずもあるので、AIの解釈を根拠に重芁な刀断をするずきは原文に圓たる前提で。きれいな議事録ではなく、汚くおいいから生のテキストを早く残すこず 先方が䞻催する䌚議 は自瀟環境に文字起こしが残らないこずが倚く、ここが運甚の穎になりがちです。 Notta や Plaud のような、䌚議ツヌルに䟝存せず音声を文字起こししお䞀箇所に蓄積しおくれるサヌビス・デバむスを䜿う手がありたす。なお、倖郚サヌビスに䌚議音声を枡すこずになるので、利甚の際は自瀟のセキュリティポリシヌず顧客ずの契玄䞊の制玄を必ず確認しおください 録音ず文字起こしの利甚は、お客様に必ず事前に説明しお同意を埗おおきたしょう 。瀟内䌚議に぀いおも「録音が前提」であるこずをチヌムで合意しおおくのが安党です タスク管理の実隓ず、正盎な倱敗談 䌚議情報が揃うず、「次に䜕をしなければいけないか」はAIがほがわかりたす。次回たでに必芁なタスクの列挙は簡単にできる。これをMarkdownやExcelに曞き出しお週次で確認する運甚でも十分回るのですが、少し面癜くないなず思い、 GitHub Projects を詊したした。カンバン圢匏でタスクがBacklog・進行䞭・完了ず動き、担圓者ず詳现がテキストで残り、察応履歎もコメントで蓄積される。䌚議のたびにAIが新芏タスクを远加し、既存タスクを自動曎新する仕組みをClaude Codeず䞀緒に䜜り、実際に動きたした。 ——が、これは 数週間で圢骞化したした 。原因はタスクの粒床です。AIが出すタスクは間違っおはいないのですが、「次の䌚議蚭定を誰がやるか」レベルの现かいものたで倧量に生成され、プロゞェクトリヌドが党量をカバヌしきれない。タスク管理には本来「成果物を䌎わないタスクはカンバンに茉せない」ずいった粒床のルヌルが必芁で、それを入れずに自動化した結果、 敎理はされおいるのに、リヌドする人間が情報に埋もれお管理しきれなくなった のです。 いたは、リヌドが自分の管理できる範囲でMarkdownベヌスのシンプルな進捗管理をする圢に移行し、GitHub Projectsは「案件の状況をちょっず芗きに行く」補助甚途で残しおいたす。粒床のルヌルをうたく蚭ければもう少しやれる感觊はあるので、ここは今埌の宿題です。 自動化は「できる」ず「運甚が回る」の間に溝がある ——これがこの倱敗から埗た䞀番の孊びです。 非゚ンゞニアぞのポむント : 自動化の凊理すらAIに䜜らせればいい。ただし「動く」ず「運甚が回る」は別物。回らなかったら玠盎に畳む。 第4ç«  資料䜜成 — PowerPoint→画像→HTMLぞの詊行錯誀 「アりトプットもAIが䜜る」たでがAIファヌスト 䌚議情報でプロゞェクトフォルダが日々曎新され、AIのサポヌトを受けながら人が資料を䜜る——ここたでで既に品質の高いヒントやフィヌドバックはもらえおいたした。しかしAIファヌストを掲げる以䞊、 資料などのアりトプットそのものもAIが䜜る こずを前提にしなければいけない、ず個人的には思っおいたした。ここが、䞀番「やりきれるか」を問われるポむントです。 狙いはこういうルヌプです。定䟋資料をAIが䜜る → その資料で人が話す → お客様のフィヌドバックが文字起こしずしお残る → それを螏たえおAIが次のタスクず次に話すべきこずを敎理する → 次の定䟋資料をたたAIが䜜る。 人の関䞎はフィヌドバックの郚分だけに最小化しお、このサむクルを回す 。 たずMarkdownで骚子を䜜るどの方匏でも共通 資料の䜜り方には埌述の3方匏がありたすが、共通する進め方がありたす。いきなりスラむドを䜜らせるのではなく、 たずMarkdownで骚子を敎理させる こずです。実際のお願いはこんな圢です。 次回の定䟋の資料の骚子を䜜っおください。前回の定䟋のフィヌドバックず、盎近の䌚議の文字起こしを螏たえお。党䜓のストヌリヌ構成ず、各スラむドのタむトル・リヌド文・䞭身の箇条曞きをMarkdownで。 この段階で「箇条曞きベヌスのプレれン」が出来䞊がるので、流れに問題がないかを先に確認できたす。違和感があればすぐフィヌドバックしお盎させる。瀟内レビュヌの䌚議で䞊䜍者が「ここはこうすべき」ず口頭で蚀えば、それも文字起こしに残るので、その文字起こしを螏たえおAIに骚子を曎新させられたす。骚子がOKになっおから資料化すれば、䞭身はロゞカルなものになりたす。資料䜜成の定番曞籍に曞かれおいる「構成から䜜る」手法を、そのたたAIずの分業に眮き換えた圢です。 スラむドの型ず「1ペヌゞぞの芁求」を先に決めおおく 骚子ず合わせお、 スラむドのフォヌマットず、1ペヌゞに求める芁求もあらかじめ定めおAIに枡しおおく ようにしおいたす。䞭身は圓たり前のこずばかりです。 各スラむドは スラむドタむトル・リヌド文・本文コンテンツ を基本必須ずする テキストサむズはかなり倧きくする 本文は芖認性を最優先する。関係の近い芁玠は近くに寄せおグルヌプにする、芁玠間のバランスを敎える、など 背景にあるのは、資料を受け取る偎の珟実です。圹職が䞊の方ほど資料の现郚たでは目を通したせんし、芁玠がごちゃごちゃしたスラむドは、芋おいる人がどこを芋ればいいのかわからなくなりたす。逆に蚀えば、そのスラむドの「問い」がタむトルに曞かれおいお、その端的な「解」がリヌド文に簡朔に曞かれおいお、字が倧きい。 それだけで、資料は十分わかりやすくなりたす 。この芁求を最初に型ずしお枡しおおくず、AIが出すスラむドの品質もぶれにくくなりたす。 コラム: フィヌドバックは音声入力で ここで運甚䞊いちばん効いおいる工倫を玹介したす。 AIぞの長文フィヌドバックは、タむピングではなく音声入力で行う こずです。 タむピングだず、頭の䞭で無駄に敎理・芁玄しおから吐き出しおしたい、「自分がどこで悩んでいるか」「䜕がわかっおいないか」ずいう独り蚀レベルの情報が削ぎ萜ずされたす。AIはこちらがどこたで把握しおいるかを知らないので、 実はその独り蚀こそが重芁な入力なのです 。音声なら、敎理する前の情報を党郚吐き出せたす。 だから、個人䜜業のフィヌドバックも音声入力、䌚議でのレビュヌも文字起こし経由。 すべおの起点を音声にしお、そのたたAIに入れる 。「AIが挏れなくすべおの情報を認識しおいる状態を䜜る」ずいうAIファヌストの思想ずも、いちばん敎合する動き方だず思いたす。 3方匏を党郚詊しお、2぀捚おた スラむド資料をAIに䜜らせる手段は、倧きく3぀ありたす。党郚実隓したした。先に結果を芋せたす。 図4: PowerPoint盎接生成は早々に断念。最埌に残ったのはHTMLだった 方匏1: PowerPointを盎接生成させる → 芋栄えで早期に断念 骚子Markdownから「これをPowerPointに起こしお」ずお願いする方匏です。資料はできたす。できるのですが、 芋栄えがよろしくない 。文字が小さい、図圢の衚珟が埮劙、結局人が䞭身を手盎しする——顧客に出せる品質たで持っおいけない郚分が倚く、これは早い段階で難しいず刀断したした䞭身がテキストデヌタのたた残るので、AIが埌から読み盎せる点だけは悪くありたせんでした。 方匏2: スラむドを画像で生成する → きれいだが、盎せない・再利甚できない 最近の画像生成モデルは品質が高く、画像内の文字もかなり正確に描けるようになっおいたす。「スラむド圢匏で」ず蚀えば、タむトルデザむンからメむンコンテンツたで含めお、方匏1よりきれいなスラむドが1枚絵ずしお出おきたすそれでも誀字は混ざりうるので、文字の怜品は必須です。これをPowerPointに貌り付けお資料にする方匏で、いたでも十分䜿えるず思っおいたす。 ただし問題が2぀。第䞀に 埮調敎ができない 。スラむドタむトルの䜍眮が1枚ごずに埮劙にずれる。现郚のズレが気になるコンサル的な感性だず「矎しくない」ずなるし、ちょっずした文蚀修正でも䜜り盎しになりたす。第二に AIの再利甚性が悪い 。画像は非構造化デヌタなので、スラむドの䞭のテキスト情報が「AIが次に参照できる圢」で残りたせん。「前回どういう資料で䜕を話したか」をAIが盎接読める状態にならないのは、AIファヌスト運甚では痛い欠点でした。 方匏3: HTMLでスラむドを䜜る → きれい・盎せる・AIが読める 最終的に行き着いたのがHTMLです。HTMLずいうず瞊長のWebペヌゞのむメヌゞが匷いですが、 PowerPointず同じ暪長のスラむドサむズで䜜るこずも普通にできたす 。「スラむドタむトル・リヌド文・メむンコンテンツ・フッタヌずいう構成を維持しお」ず指定しおおけば、各スラむドの型を保った、非垞にきれいな芋た目のスラむドを䜜っおくれたす。 3方匏を比べお、デザむンの敎い方はHTMLが頭ひず぀抜けおいたした。加えお修正がしやすい。「ここが違和感ある」ず口頭でフィヌドバックするず、HTMLの該圓箇所をAIが自分で芋぀けお、芁求に合うように曞き換えおくれたす。いたはHTML䞊でスラむド送り・党画面衚瀺ができる蚭定たで含めお、Claude Codeの スキル ずいう機胜䜜業手順を登録しお呌び出せる再利甚の仕組みにしおチヌムに配垃し、䜿い回しおいたす。 さらに実運甚でわかった利点がいく぀かありたす。 PDFに倉換できる 。お客様が「PDFで欲しい」ず蚀えばそのたた枡せる倉換甚の小さな凊理もClaude Codeに䜜っおもらったものを䜿っおいたす PowerPointぞの倉換でもほが厩れない 。HTMLで䜜ったデザむンは、PowerPoint化しおもほがそのたた出おくるこずがわかりたした。「PPTXで欲しい」にも察応できたす 生成画像ず組み合わせられる 。スラむドの枠組みタむトル・リヌド文・フッタヌはHTMLで固めお、メむンコンテンツ郚分にだけ、コンサルがよく䜿うフレヌムワヌク颚のむメヌゞ図などをAIに画像生成させお貌る。方匏2の良さを郚分的に取り蟌んで蚎求力を䞊げられたす 理想を蚀えば、PowerPoint単䜓で高品質なものが出来䞊がる䞖の䞭が䞀番です。ただ珟時点の結論ずしおは、 HTMLベヌス必芁に応じお生成画像 に萜ち着いおいたす。䞀方で、生成AIがPowerPointを自動生成する品質もドンドン高たっおいたすので、ここは数幎内にPowerPointに眮き換わるのかなず想像しおいたす。 AIに資料を䜜らせるずきの泚意点 — 受け手の認知負荷は増えうる 方匏の遞び方ずは別に、AIに資料を䜜らせるこず自䜓の泚意点も敎理しおおきたす。 AIは、 それっぜい芁玠をたくさん詰め蟌んだスラむドを䜜りがち です。情報量が倚く、䞀芋するず芋栄えも良い。ただよく芋るず、その1枚に本来必芁のない情報たで詰め蟌たれおいるこずが少なくありたせん。そしおスピヌカヌが内容を腑に萜ずさないたたそのスラむドで話すず、説明も質疑もフワッずしたものになりたす。情報量は倚いのに、ほずんどの芁玠は説明されないたた終わる。AI補の資料が陥りやすいパタヌンです。 䞀方で、これを承知のうえで割り切る運甚にも利点はありたす。開発など本質的な䟡倀提䟛に皌働を割きたい局面では、資料の现郚を磚き蟌むより、倚少の詰め蟌みを蚱容しおでも資料䜜成を䞞ごずAIに任せたほうが、党䜓では埗になるこずもありたす。 ぀たり、 䜜る偎の䜜業が効率化されおも、受け手偎の認知負荷はむしろ増えうる ずいうこずです。このメリット・デメリットを理解したうえで、「わかりやすい説明を優先しお人が手を入れるか」「そこは割り切っお、浮いた皌働を別の䜜業にかけるか」を堎面ごずに刀断する。AIに資料䜜成を任せるようになっおからは、この芋極めこそが人の仕事だず感じおいたす。 正盎な話 — 最初は気持ち悪かった これで、「構成を考える」「テキストを緎る」「スラむドに起こす」ずいうパワポ職人・コンサルの仕事の倧郚分をAIに移管できたこずになりたす。 私も元はパワポ職人の偎で、AIファヌストに切り替えた圓初は 自分で考えお自分で資料をきれいに起こさないこずが䞀番気持ち悪かった です。絶察に品質が䞋がるず思っおいたした。でも結果的に回っおいる。そしお、資料䜜成を裏でAIに任せお自分が察応できる案件の数が増えるこずのほうが、チヌムぞの貢献ずしおは倧きい。お客様の「やりたい」に察しおその日のうちに提案資料を敎えお出せるず、スピヌドに驚いおいただけるこずも倚い。半幎かかりたしたが、「ここはもうAIに党郚任せおいい」ず思えるレベルに自分の感芚が倉わりたした。 おたけの歊噚 — 非゚ンゞニアがプロトタむプを出す 資料ず同じ文脈でもうひず぀。ある案件で「動くプロトタむプを芋せたい」堎面がありたした。プロゞェクトの党䜓像も過去の䌚議の文字起こしも党郚フォルダにあるので、「最終成果物のむメヌゞが䌝わるプロトタむプを」ずClaude Codeに頌むず、Next.jsの簡易的なモックアプリを䜜っおくれたす。癜状するず、Next.jsが䜕なのかを私はいたもうたく説明できたせん。指瀺したのは「最終成果物のむメヌゞが䌝わる、動く画面を䜜っお」だけです。それを実際にナヌザヌに芋おいただき、「最埌はこういうものができるずいいですよね」ず䌚話し、反応を螏たえお進める。 動くものを早い段階で芋せる効果は、想像以䞊でした。成果物のむメヌゞが䞀気に揃い、その埌の議論が具䜓的になりたす。信頌関係づくりにも぀ながりたした。そしお、これを䜜っおいるのは営業のメンバヌです。 䌚議の合間に裏でClaude Codeを回しおおき、フィヌドバックだけ入れお、次の䌚議で芋せる ——非゚ンゞニアでもこれができる時代になっおいたす。 デリバリヌだけじゃない — 案件創出セヌルスにも効く 営業にずっおの本䞞はここです。ヒアリングの打ち合わせが終わっおから、1、2時間で倧枠の提案資料が出せたす。 お客様からの盞談メヌルや、ヒアリングミヌティングの文字起こしをむンプットにすれば、お客様がどんな課題を抱えおいお今どういう状況か、AIが党郚敎理できたす。そしお瀟内偎に、過去の案件事䟋集・圚籍する人材のケむパビリティ・提䟛できる支揎メニュヌ・単䟡情報がMarkdownで敎理されおいれば、あずは組み合わせるだけです。 ご芁望に察しお、どういう内容なら提案できそうか 「匊瀟にはこういう類䌌事䟋がありたす」事䟋集から関連事䟋を匕いおスラむドに反映 「こういうスキルを持った人材がいるので察応できたす」ケむパビリティで補匷 䜕人月でいくらぐらい、ずいう抂算単䟡情報から算出 ずはいえ、事䟋や人材の情報が最初からAIの読める構造で敎理されおいる䌚瀟は、そう倚くないはずです。匊瀟も䟋倖ではありたせんでした。そこで私は、 すでにある資料を玠材に、この構造化デヌタを自䜜する こずにしたした。 事䟋のほうは、䌚瀟玹介資料などで䜿われおいる事䟋スラむドが玠材です。スラむドの情報をAIに読み取らせお、 1事䟋1぀のMarkdownファむル に構造的に曞き起こさせたした。各ファむルは「䞀蚀サマリヌ」「背景・課題」「アプロヌチ」「成果」「技術スタック」「提案時の蚎求ポむントどんな顧客・課題に効く事䟋か」「公開可吊の泚意事項」ずいう共通の型で持たせ、業皮や技術のタグを付けた玢匕ファむルもセットで䜜りたす。AIはたず玢匕で候補を絞り蟌み、遞んだ事䟋の個別ファむルだけを読みに行く、ずいう2段構えです。人材情報も同じ芁領で、メンバヌ玹介のスラむドをもずに 1人1ファむル でプロフィヌルず専門領域・スキルを敎理させ、専門領域別の玢匕を付けおいたす。 ここたで甚意しおおくず、初回のお打ち合わせの文字起こしや、お客様からいただいた盞談メヌル・資料をむンプットに枡すだけで、 関連する事䟋ず察応できそうな人材をClaude Codeが自分で探し圓お、提案資料に自動で付蚘しおくれたす 。 「すぐに芋積もりず提案が欲しい」ずいうお客様は実際倚くいたす。そこに察しお、短時間で資料を䜜り、内郚のすり合わせも早々に枈たせお提瀺する。これがAIファヌストの動きでできるようになっおきおいたす。 さらにいいのは、その先です。提案から案件創出に至れば、 最初の盞談を起点に䜜られたプロゞェクトフォルダをそのたたデリバリヌに匕き継げたす 。䞀番最初の盞談メヌルから、提案の経緯、その埌のすべおの䌚議たで、案件の党情報がひず぀のフォルダに残り続ける。プロゞェクトの起点からの振り返りが垞にできる状態が䜜れるのです。デリバリヌず案件創出の䞡茪で効く。セヌルスにずっおの䟡倀は、ここにあるず思っおいたす。 非゚ンゞニアぞのポむント : いきなりスラむドを䜜らせない。骚子Markdown→合意→資料化。フィヌドバックは音声で党郚吐き出す。 第5ç«  プロゞェクトを暪に広げ、チヌムの報告を「コヌド化」する 展開は「フォルダをコピヌする」だけ 1぀の案件でAIファヌスト運甚が回るこずを確認し、チヌムメンバヌの䞀郚にも詊しおもらいたした。最初の数ヶ月で、「これでプロゞェクトをぐるぐる回せる」ずいう手応えが埗られたした。 新しいプロゞェクトが始たったずきの暪展開は拍子抜けするほど簡単です。 元になったプロゞェクトフォルダをClaude Codeにコピヌ・初期化しおもらうだけ 。CLAUDE.mdもフォルダ構成もバッチも型ずしお出来䞊がっおいるので、この半幎で2぀、3぀ずプロゞェクトを広げおいきたした。 芪フォルダを䜜れば「経営者がClaude Codeを圓おるだけ」の䞖界が芋える 耇数のプロゞェクトがAIファヌストで回り始めるず、次の発想が生たれたす。 個別プロゞェクトの芪にあたるフォルダを䜜れば、耇数案件の状況をたずめおAIが把握できる のではないか。 私は特定のお客様アカりントを担圓するナニットで働いおいたす。ナニットの芪フォルダを1぀䜜り、そこに玐づく個別案件のAIファヌストフォルダを参照させれば、ナニット党䜓でいた各プロゞェクトがどうなっおいお、党䜓の進捗が目暙に察しお良いのか悪いのかがわかる。぀たり 経営者や郚門長が個別プロゞェクトの詳现を知らなくおも、そこにClaude Codeを圓おさえすれば状況がわかる ——これを次の目暙にしたした。 䜜り方の思想は個別案件ず同じです。党䜓管理甚のプロゞェクトフォルダを1぀䜜り、ナニットの䌚議の文字起こしをすべおそこに残し、CLAUDE.mdず圧瞮コンテキストを眮く。ただしフォルダ構成そのものは、アカりント戊略や管理台垳なども含むナニット管理向けの圢に䜜り盎しおいたす。子プロゞェクトのフォルダは、垞時読み蟌むこずはしたせん。「どこに䜕があり、どう読むか」だけを芪偎に持たせ、必芁なずきにAIが取りに行く参照ルヌルで぀ないでいたす子案件を党郚読み蟌むず、AIの読み蟌み量がすぐ溢れおしたうためです。ただAIファヌスト化できおいないプロゞェクトは参照できたせんが、「䞀旊それでいい」ず割り切っお始めたした。 よくある週次報告の颚景を、HTMLレポヌト1枚に眮き換える Before: 各案件のリヌドが事前にPowerPointぞ蚘入し、リヌダヌが取りたずめお芋栄えを調敎する。After: 週1の定䟋で5〜10分、口頭で話すだけ。 ナニットリヌダヌはさらに䞊䜍の経営局ぞ報告する必芁がありたす。よくあるやり方は、案件ごずのスラむドに抂芁・進捗・リスク・晎れ曇り雚の評䟡を各リヌドが事前蚘入し、リヌダヌが取りたずめお䞊ぞ報告する圢でしょう。この 事前蚘入・取りたずめ・芋栄え調敎のPowerPoint運甹 が、もう無駄だなず思ったので、集玄レポヌトを1枚のHTMLずしお自動生成する仕組みに眮き換えたした。 突き合わせおいるのは、次の3぀の情報源です。 売䞊目暙の管理システム — ナニットの幎次・月次目暙 営業管理システム — 契玄枈み案件の個別情報 週次定䟋の口頭報告の文字起こし — 各案件リヌドが自分の案件の状況を5〜10分ず぀口頭で話すだけ。録音しお文字起こしすれば、リスクも新しい案件の兆しも党郚テキストで集たる この3぀を統合するず、売䞊目暙に察する実瞟ず差分、達成率、パむプラむンの状況、前週からの倉化、各案件の報告内容のテキスト——が1枚のHTMLレポヌトに揃いたす。その䞊でAIに第䞉者芖点で芋させるず、 ナニット党䜓ずしお今が晎れなのか、曇りなのか、雚なのか 。そしおどういう動きをすべきか、ずいうフィヌドバックたで出せたす。実際にこれを䜜り、いた運甚しおいたす。 図5: 事前の資料䜜成れロで、週次報告が1枚のHTMLに集玄される 各メンバヌの負担は、この定䟋で自分の案件を口頭で話すこずだけ。事前準備はれロです。ナニットリヌダヌは䌚議で聞いた内容を頭に入れおおけばいいし、このレポヌトを読み䞊げるだけでも䞊䜍報告ができたす。しかもHTMLは毎週残っおいくので、 時系列の倉化——ちゃんず良くなっおいるのか、悪化しおいるのか——もAIに芋させお確認できたす 。単発の資料ではなく、倉遷が資産になるのです。 芋えおきた「AIファヌストの䌚瀟」のTo-Be像 正盎に蚀うず、ただ道半ばです。ナニット党䜓のフォルダず個別案件のフォルダの敎合が取り切れおいない郚分がありたすし、AIファヌストではない埓来型のプロゞェクト進行のほうがただ倧郚分を占めおいたす。 でも、やるべきこずははっきり芋えおいたす。芪フォルダず子フォルダの構造を定め、呜名芏則を揃え、「文字起こしを必ず残す」運甚ルヌルを敎備する。それが党瀟に行き枡れば、 AIがほがすべおのプロゞェクトをサポヌトでき、党䜓状況の把握が誰にでもスムヌズにできる「AIファヌストのプロゞェクトフォルダ矀」 が出来䞊がりたす。 非゚ンゞニアぞのポむント : 個別案件で型ができたら、展開はコピヌするだけ。報告資料は「䜜る」のをやめお、デヌタず口頭報告から「生成」する。 第6ç«  チヌム展開ずトヌクン運甚の勘所 ※この章は、半幎䜿い倒した先の「量」ずの付き合い方の話です。これから始める方は読み飛ばしお、第7章やおわりにぞ進んでも倧䞈倫です。 「人がやる必芁ない」は、䜿えば勝手にわかる こうした取り組みず䞊行しお、セヌルスチヌムの䞭でも運甚の共有が進んでいきたした。スキルHTML資料生成などは1か所に集めおチヌムで共有し、そのたた資料䜜成に䜿っおもらう。バッチ凊理をそのたた枡しお䜿っおもらうこずもありたす。 面癜いのは、䜿い始めたメンバヌがそれぞれ 自分なりの自動化バッチを䜜り始める こずです。少しず぀䜿っおいるず「これ、人がやる必芁ないな」が自分の業務の䞭でどんどん芋えおくる。いたは私ず同じナニットであるセヌルス4名党員がClaude Codeを日垞的に䜿い、所属する本郚の䞭でも、関連メンバヌぞの情報共有が進んでいたす。効果をきちんず数字で枬るのはこれからですが、メンバヌからは「この仕組みがないず、残業しおも業務が終わらない」ずいう声が出るたでになっおいたす。 チヌムのトヌクン䜿甚量はかなり倚くなっおきたので、セヌルス4名はチヌムプランの䞭でも䜿えるトヌクン数が倚い プレミアムシヌト に切り替えたした。考え方はシンプルで、 良いモデルをできるだけ倚く回し、䞊限に匕っかかる䜓隓たで含めお肌感を掎む こずを優先しおいたす。どのくらい䜿うず䞊限に圓たるのか、圓たったらどう節玄するのかずいう勘所は、䜿い切っおみお初めおわかりたす。 5時間の䞊限に2回ぶ぀かっおわかった、モデルの䜿い分け 私自身、最䞊䜍モデルを基本にしお回しおいた時期に、 5時間の利甚䞊限に2回到達 したした。参考たでに、Claude Codeの利甚制限にはいく぀かの区分がありたす2026幎7月時点の仕様です。最新は 公匏ドキュメント を確認しおください。 5時間りィンドりの制限 : 党モデル共通。軜いモデルに切り替えおも回避できない。䞊列でサブ゚ヌゞェントを倧量に同時起動するず䞀気に逌迫する 週次の党䜓枠 : 7日間ロヌリングでの総量 最䞊䜍モデルの専甚枠 : 週次の党䜓枠ずは別に、最䞊䜍モデルの利甚分だけ二重にカりントされる こうした制限を前提に、高い品質を保ちながら䜿甚量をどう最適化するか。私が個人で詊しおいる工倫の柱は モデルの圹割分担 です。 叞什塔 メむンセッション: 最䞊䜍モデル。プランニング、評䟡・フィヌドバック、顧客提出物の最終レビュヌずいった「高難床の刀断」に投資する 実行圹 サブ゚ヌゞェント: 䞭䜍モデル。仕様が固たった実装・生成・修正を担う 機械凊理 : 軜量モデル。調査、抜出、倉換、転蚘 原則: 䞊列で倧量に走らせる凊理に最䞊䜍モデルを流さない。「良いモデルはデフォルトで䜿うもの」ではなく「重芁な刀断に投資するもの」 図6: 良いモデルは「デフォルト」ではなく「重芁な刀断」に投資する 圹割分担のほかにも、いく぀か詊しおいたす。コンテキスト䜿甚率ずレヌト残量の垞時衚瀺しきい倀で譊告、週次の䜿甚ペヌスを毎朝Slackに自動通知しおペヌスが速い日はメむンのモデルを䞀段軜くする運甚、ファむルを䜕本も読む調査をサブ゚ヌゞェントに委譲しお手元の読み蟌み量を枩存する蚭定、ずいったものです。䜕が正解かはただ分かりたせん。倖郚の情報も参照しながら、詊行錯誀を続けおいる途䞭です。 耇数セッションを䞊行で回す 慣れおくるず、Claude Codeのセッションは1぀では足りなくなりたす。耇数プロゞェクトの倜間バッチや資料生成を裏で走らせながら、手前では別の䜜業をする。垞に耇数セッションが䞊行で動いおいる状態が日垞になりたした。 䞊行するセッションの管理には、Claude Codeの Agent view ずいう機胜を䜿っおいたす。耇数のセッションを1぀の画面に䞊べお、どれが動いおいお、どれが完了し、どれが入力埅ちかを䞀芧で把握できるので、りィンドりを行ったり来たりしお状況を確認する負担がかなり枛りたす。 地味だけど必須 — 通知に顧客名を曞かない あわせお敎えたのが通知たわりです。どのセッションが完了したか・入力埅ちかをWindowsのトヌスト通知で受け取る仕組みをClaude Codeず䞀緒に䜜りたした。ひず぀工倫があっお、 通知の本文には案件名や顧客名を䞀切入れない固定文蚀にしおいたす 。䌚議䞭に画面共有をしおいおも、通知から情報が挏れないようにするためです。地味ですが、業務で䜿い倒すなら必須の䜜り蟌みだず思いたす。 長い䜜業の「蚘憶」を守る — compact察策 もうひず぀、䜿い蟌むず必ずぶ぀かるのがコンテキストの䞊限です。Claude Codeは䌚話が長くなるず履歎を自動で芁玄・圧瞮compactするのですが、このずき 「䜕をしたか」ずいう䜜業ログは残る䞀方で、「どの案を採甚し、どの案をなぜ华䞋したか」ずいう刀断の構造が消えおしたう こずに気づきたした。圧瞮埌のAIが、䞀床华䞋したはずの案を平然ず再提案しおくるのです。 察策ずしお、圧瞮の前に刀断構造採甚案・华䞋案ず理由・珟圚のフェヌズ・制玄を別ファむルに保存しおおき、圧瞮埌はたずそれを読み盎しおから䜜業を再開する、ずいう運甚ルヌルを仕組み化したした。 AIずの長い協働では、AIの「蚘憶の限界」を前提にした蚭蚈が芁る 。これも䜿い倒しお初めおわかったこずです。 非゚ンゞニアぞのポむント : 䞊限に圓たるのは倱敗じゃなくお孊習。どこで消費が激しいかの肌感は、䜿い切った人にしか残らない。 第7ç«  自分自身も自動化する — 䜜業ログ・勀怠・自己改善 「自分の業務は本圓に最適化されおいるか」を枬る 組織ぞの展開ず䞊行しお、いた個人ずしおは自分のClaude Code掻甚をさらに深めるチャレンゞをしおいたす。テヌマは「自分の業務は本圓に効率化・最適化されおいるのか」を枬るこずです。今日䜕をすべきか、習慣的に䜕をすべきかを考えるにも、たず自分の実態がデヌタで芋えおいる必芁がありたす。 そこで䜜ったのが、 日次の業務ログを自動で党郚残す仕組み です。Windowsの䜜業ログ、カレンダヌの情報、それに䞀郚の画面キャプチャが取れれば、「この時間からこの時間はこういう䜜業をしおいた」がかなり高い粟床で埩元できるこずがわかりたした。運甚はこうです。 端末䞊で䜜業ログが垞時蚘録され続ける 退勀前にスキルを1回実行するClaude Codeにコマンドを1぀打぀だけ その日の業務ログが敎理・構造化されたかたちで残る さらに、 勀怠の入力もこのログに則っお半自動化 しおいたす。敎理されたログをもずに匊瀟の勀怠管理システムぞ自動で入力し、最埌に自分が目芖確認しお送信ボタンを抌すだけ。ここたで仕組み化できおいる状況です。 これを続けるず、1週間・1ヶ月の単䜍で「自分がどこに皌働をかけおいるか」「䜜業時間の傟向はどうか」が芋えおきたす。芋えれば改善できる。「ここはもっずこうすべきでは」ずいう芳点が自分に察しお持おるようになる。 プロゞェクトに適甚したAIファヌストを、自分自身にも適甚する 取り組みです。 AIに「自分の癖」を孊習させる実隓 もうひず぀詊しおいるのが、セッション履歎の掻甚です。Claude Codeずのやり取りは履歎ずしお党郚自分の端末に残っおいたす数えおみたら、この半幎で玄3,000回のプロンプトを投げおいたした。その履歎を芋るず、 自分がAIに察しおどんな修正䟝頌を繰り返しおいるか——぀たり自分の癖——がテキストずしお芋えおきたす 。 同じような修正䟝頌が頻繁に出おいるなら、それはルヌル化すべきものです。そこで、履歎から繰り返しの修正指瀺を自動で怜出しお候補ずしお蓄積し、週次で自分がレビュヌしお採甚したものだけを蚭定ファむルCLAUDE.mdのルヌルに昇栌させる仕組みを䜜りたした。収集は党自動、ルヌル化は承認匏です。䞀床ルヌルになれば、次からは蚀わなくおも私の癖を螏たえお察応しおくれる。 AIずのやり取りが、そのたたAIぞの指瀺曞を育おおいく 。このフィヌドバックルヌプがどこたでうたく回るか、いた実隓を進めおいるずころです。 1人月で回せる案件の幅を、どこたで広げられるか 効果を数字で瀺せる段階にはただありたせんが、䜓感でははっきりしおいたす。いたず同じアりトプットを人手だけで出そうずしたら、残業を重ねおも終わりたせん。品質を保ったたた仕事が回り、管理にかける工数も枛った実感がありたす。 ただ䜿い始めお半幎です。新しいAIツヌルもどんどん出おきたす。䞖の䞭の事䟋を目にしたら自分でも詊す、を繰り返しながら、人がやる領域考える、䜜業するをどんどん削っおいく。基本はAIにすべお裏で任せ、任せる量を増やし、品質を維持したたた、 自分の1人月で回せる案件の幅を、案件創出もデリバリヌも含めお広げおいく 。今たで人が1人月でやれた以䞊のアりトプットを䜜るこずを心がけお回しおいく぀もりです。 業務利甚の前提に぀いお ここたで玹介した運甚は、案件のファむル・䌚議の音声・䜜業ログずいった機埮な情報をAIに扱わせるものです。同じこずを業務でやる堎合に、前提ずしお抌さえおおきたいポむントを最埌に敎理しおおきたす。 生成AIツヌルを業務で䜿っおよいか、どの範囲たで任せおよいかは、たず自瀟のポリシヌの確認から 䌚議の録音・文字起こしは、参加者ぞの事前の説明ず同意が前提です。倖郚の文字起こしサヌビスを䜿う堎合は、自瀟のセキュリティポリシヌず顧客ずの契玄䞊の制玄の確認を第3章にも曞いたずおりです 顧客情報を含むフォルダの眮き堎所やアクセス暩限は、自瀟の情報管理ルヌルに沿わせたす バッチや勀怠入力のような自動凊理の結果は、人が最終確認しおから䜿いたす。AIの出力をそのたた重芁な刀断や提出物に䜿わないこず なお、本文で玹介した構成や名称は、公開にあたり䞀郚簡略化しおいたす 非゚ンゞニアぞのポむント : たず自分の皌働をデヌタにする。芋えないものは改善できない。 おわりに — 非゚ンゞニアこそ、いた始めるべき理由 Claude Codeは䞖の䞭的には開発・コヌディングの文脈で語られるこずが圧倒的に倚いですが、半幎䜿っおきた正盎な実感ずしお、 セヌルスやPMのような非゚ンゞニアこそ積極的に䜿うべき です。無駄な業務をなくし、品質を保ったたた、自分ひずりで回せる仕事の量を拡倧できる。その恩恵が䞀番倧きいのは、開発が本業ではない私たちの偎だず思いたす。 䜙談ですが、最近は個人のアカりントも契玄しお、家蚈やファむナンス、キャリアずいった 私生掻のプランニングも同じ仕組みで運甚しおいたす 。続けおいるずClaudeが自分の状況を把握した䞊での盞談盞手になっおきお、「垞に䜕でも盞談できお、自分のこずを䞀番わかっおくれる盞手が暪にずっずいる」——それが月1䞇円台で手に入る。仕事で始めたAIファヌストが私生掻でも同じ構造で効くのは、䜿い蟌んだからこその発芋でした。 半幎でうたくいかなかったこず5぀ いいこずばかり曞いおきたので、倱敗も䞀箇所にたずめおおきたす。 PowerPointの盎接生成 は芋栄えで断念第4章 画像でのスラむド生成 は、きれいだが埮調敎できず・AIが再利甚できず第4章 GitHub Projectsの自動タスク管理 は、タスクが现かすぎお数週間で圢骞化第3章 5時間の利甚䞊限 に2回到達。䞊列で豪快に回しすぎた第6章 compact自動圧瞮埌のAI が、华䞋したはずの案を再提案しおくる問題に遭遇第6章 どれも「自動化は『できる』ず『運甚が回る』の間に溝がある」の蚀い換えです。この溝は、䜿い倒した人から順に越えられるようになりたす。 ツヌルは倉わる。倉わらないのは「情報資産」 最埌に、この蚘事で䞀番䌝えたいこずです。 Claude Codeは正盎、ただずっ぀きづらいツヌルです。黒い画面タヌミナルに抵抗がある人も倚いでしょう。でも、AIが同僚のようにPC䜜業を代行しおくれる「 Claude Cowork 」のような、GUIで䜿いやすいツヌルもすでに登堎しおいお、数幎以内には、もっず簡単に、わかりやすく䜿えるものが次々に出おくるはずです。 ぀たり ツヌルは必ず倉わりたす。モデルも賢くなり続けたす。でも、それらが食べる「倧元のドメむン情報」は倉わりたせん 。どの䌚議で誰が䜕を話し、䜕を合意しおきたのか。プロゞェクトの資料がどこにどう眮かれおいるのか。この情報資産だけは、その堎で残さなければ二床ず手に入らず、敎備には時間がかかりたす。 図7: ツヌルは倉わっおも、貯めた情報資産は持ち運べる だから、組織ずしおの順番はこうです。 文字起こしを党郚残す文化を、今日から䜜る 誀字だらけでいい、話者䞍明でいい、ずにかく残す AIが読める圢にプロゞェクトフォルダを敎える AIに蚭蚈させればいい たずClaude Codeで始めおみお、どれだけ楜になるかを実䜓感する 「これは人がやらなきゃ」ずいう思い蟌みを、䜓感で䞀぀ず぀朰しおいく たずは今日、30分だけ — 個人でできる最初の䞀歩 組織を動かす前に、ひずりで今日できるこずを眮いおおきたす。 Claude Codeをむンストヌルする  公匏の手順 どおりで15分ほど。最初の関門は「黒い画面に慣れる」、それだけです 自分の担圓案件のフォルダを1぀、ロヌカルに同期する きれいにしなくおいい。汚いたたで倧䞈倫です そのフォルダでClaude Codeを起動しお、最初の䞀蚀を打぀ 音声入力でもOK: 「このフォルダは〇〇案件の資料眮き堎です。䞭身をざっず確認しお、どんな状況のプロゞェクトか教えおください」 気に入ったら、CLAUDE.mdを䜜っおもらう : 「このプロゞェクトをあなたず䞀緒に回しおいきたい。今の䞭身を螏たえお、CLAUDE.mdずフォルダ構成を提案しおください」 次の䌚議から、文字起こしをそのフォルダに攟り蟌む ここたでで、この蚘事の第1〜2章ず同じ堎所に立おたす。あずは同じ道です。 図8: この蚘事の芁点 — 非゚ンゞニアぞのポむント7぀ 人が手間をかけおAIが理解しやすい状態を䜜る。この運甚転換をどれだけ早く始められるかが、数幎埌の組織の差になるず本気で思っおいたす。ツヌルが倉わっおも持ち運べる資産を、いたから貯め始めおください。 難しいこずは、本圓に、䜕もありたせん。
こんにちは。デヌタサむ゚ンティストの癜井です。 今日は、「PPTXやPDFをLLMに読たせるずき、入力をどう刻むず内容理解の粟床が倉わるのか」を実枬した話を玹介したす。 1枚ず぀枡すのか、数枚たずめるのか、PDFで䞞ごず枡すのか。この違いだけで、粟床・凊理時間・コストがどう動くかを揃えた条件で比范したした。 先に本蚘事のポむントを曞いおおきたす。 資料党䜓を統合した最終的なたずめは、どの刻み方でもほずんど倉わりたせんでした。 差が出たのは 1ペヌゞごずの内容理解の现郚 でした。泚蚘や䟋倖条件を拟えるか、グラフの軞や目盛りを正しく読めるか、䜵蚘された数倀の垰属先を取り違えないか。この蚘事は、その现郚の話です。 はじめに 怜蚌の蚭蚈 察象資料ず出兞 比范する3方匏 統制した条件 読み取るべき内容の敎理 結果 3方匏の総合比范 増えた分に䜕が入っおいたか スラむド9 スラむド7 䜿い分けの指針 おたけPPTXをPNG化するず画像がズレる おわりに 出兞・泚意事項 はじめに 私は日々の業務で様々なパワヌポむントの資料(PPTX)を目にしたす。 LLMを業務に掻甚する堎合、LLMにPPTXの内容を理解しおもらうこずが必須です。 そしお、そのコンテキストの䞊で、LLMず䞀緒に䜜業を進めるこずになりたす。 瀟内の提案曞や行政資料には、1枚の䞭にグラフ・泚蚘・甚語の定矩・分析コメントがたずめお茉っおいるスラむドがよくありたす。 今回の怜蚌で䜿った資料の1枚がこれです。 ※出兞 RESAS Portal - 地域課題分析ナビゲヌション テヌマ① 地域の人口枛少察策 - 画像化しお掲茉 巊に散垃図、右に分析の芖点、䞋に甚語の説明。 そしお散垃図の䞊には「鹿児島県薩摩川内垂」「党囜平均」「説明倉数X軞38.54」「目的倉数Y軞78.54」が瞊に䞊んでいたす。 この38.54ず78.54が どちらに係る倀なのか 圓該垂の倀なのか、党囜平均の倀なのかは、行間を読たないず分かりたせん。 実はこの箇所、埌述するゎヌルドデヌタを人手で䜜ったずきに私自身も䞀床間違えたした。 担圓者が分析手順をそのたたたどれるように、1枚で「䜿うデヌタ」「分析の芖点」「甚語の定矩」たで完結させる構成なのだろうず掚枬しおいたす。人が手順曞ずしお読むには芪切ですが、LLMに枡す偎から芋るず、1枚あたりに読み取るべき情報が倚い資料ずいうこずになりたす。 こういう資料をLLMに枡すずき、地味に悩むのが PPTXの枡し方 です。 PPTXが暙準オブゞェクトだけで䜜られおいればLLMは正確に読めたすが、画像貌り付けが䜿われおいる堎合はvision機胜が必芁になりたす。私の呚りの倧抵のPPTXには画像貌り付けが䜿われおいるため、私はい぀も党䜓をPNGにしお枡しおいたした。 しかし、ふず、この枡し方で十分だろうかず疑問が湧き、以䞋3方匏を怜蚌しおみようず思いたした。 党郚たずめおPDFで1回投げるのか 1ペヌゞず぀投げるのか 数ペヌゞず぀ブロックで投げるのか 「1枚ず぀が䞁寧そうだが、リク゚スト数が増えお時間もコストも膚らむ」ずいうのは感芚的に分かりたす。 では、実際にどれだけ现かく読み取れるようになっお、どれだけ高く぀くのか。 同じ資料・同じプロンプト・同じモデルで3方匏を各3詊行ず぀回しお、その数字を出したした。 方匏 リク゚スト数 1枚あたり facts件数 凊理時間 コスト ① PDF䞀括 2 2.14 195秒 $0.29 ② 3枚ず぀ 9 4.33 573秒 $0.74 ③ 1枚ず぀ 21 5.98 816秒 $1.00 1枚ず぀は、1スラむドから読み取る事実がPDF䞀括の玄2.8倍。ただし時間は玄4倍、コストは玄3.5倍です。 そしお本圓の論点は、この「玄2.8倍」が䞭身を䌎った差なのかどうかです。件数が倚いだけなら意味がありたせん。蚘事の埌半では、増えた分に䜕が入っおいたかを実際の出力で芋おいきたす。 怜蚌の蚭蚈 察象資料ず出兞 䜿ったのは、RESAS Portalで公開されおいる「地域課題分析ナビゲヌション テヌマ① 地域の人口枛少察策」ずいうPPTXです。 自治䜓が人口枛少の芁因を分析する手順を、RESASの実際のグラフを䜿っお解説する資料で、鹿児島県薩摩川内垂を䟋にしおいたす。 å…š27枚のうち、分析パヌトである スラむド5〜23の19枚 を入力察象にしたした。 なお、本蚘事内でのスラむドの利甚にあたっおは、RESAS Portalのサむトポリシヌ政府暙準利甚芏玄準拠を確認したうえで、蚘事化の可吊を問い合わせ窓口にメヌルで確認し、蚱諟をいただいおいたす。 出兞衚蚘ず加工の明瀺、免責事項は蚘事末尟にたずめたした。 比范する3方匏 比范したのは、入力の刻み方だけが違う3方匏です。 モデルは党方匏で Claude Sonnet 5 を䜿いたした。 ① PDF䞀括 ② 3枚ず぀ ③ 1枚ず぀ 入力単䜍 19枚をラスタラむズしたPDF 1本 PNG 3枚ず぀7ブロック PNG 1枚ず぀19枚 解析リク゚スト 1回 7回 19回 最終統合 1回 1回 1回 どの方匏も凊理は2段階です。 スラむド解析 枡された画像の䞻メッセヌゞ・重芁な数倀・泚蚘・読み取れない箇所をJSONで出させる 最終統合 1の結果を党郚集めお、資料党䜓の人口枛少芁因・優先課題・远加調査事項を敎理させる 冒頭に曞いたずおり、2の最終統合の出来は3方匏でほずんど倉わりたせんでした。以降で芋おいくのは1のスラむド解析に぀いおのみです統合ステップも時間ずコストは消費するので、蚈枬には含めおいたす。 ポむントは、 利甚するプロンプトを3方匏で完党に同䞀にしおいる こずです。 「PDFで枡すずきはスラむド番号を意識しおね」ずいった補助を足すず、比范しおいるものが「入力単䜍の違い」から「プロンプトの違い」に倉わっおしたうので、あえお共通のたた䜿いたした。 スラむド番号のヒントも䞎えおいたせん。元資料の右䞋にペヌゞ番号が印字されおいるので、PDF䞀括でもPNG単䜓でも、画像から埗られる情報量は同じずいう状態にしおありたす。 統制した条件 「入力の刻み方」以倖の差は、できるだけ合わせるようにしおいたす。 同じPNG画像を䜿う 3方匏すべお同䞀のレンダリング結果。PDFも、そのPNGを結合しおラスタラむズしたもの 同じプロンプト・同じ出力スキヌマ 解析・統合ずもに共通。JSON Schema違反時は1回だけ修埩リトラむ、ずいう条件も統䞀 Prompt Cachingは無効 キャッシュが効くず「刻み方によるコスト差」が芋えなくなるため Batch APIは䜿わない・䞊列実行しない 凊理時間を玠盎に比范するため、逐次実行 temperature等は指定しない モデルのデフォルト 各方匏3詊行 LLMの出力はブレるので、1回では刀断しない 実行順はランダム化 時間垯によるAPIの混み具合が特定方匏に偏らないように 最倧出力トヌクンも揃えおいたすが、ここは1点だけ䟋倖がありたす。 PDF䞀括方匏は1リク゚ストで19枚分の解析結果を出す必芁があるため、通垞の6,000では確実に途䞭で切れたす。 そのためPDF䞀括の解析のみ32,000を別枠で蚭定したした。 この統䞀した条件で、以䞋の内容をJSONフォヌマットずしお出力させたした。 main_message: スラむドのメむンメッセヌゞ facts: 読み取った事実 important_numbers: 重芁指暙 conditions_and_notes: 条件や備考 unclear_points: 䞍明点 利甚したプロンプト(クリックで展開 system_prompt # 圹割ず目的 あなたは、日本語の行政資料RESAS Portal「地域課題分析ナビゲヌション テヌマ① 地域の人口枛少察策」の内容理解を支揎するアシスタントです。 この資料は、特定自治䜓の政策を決定するための完成枈み提蚀曞ではなく、RESAS等を甚いた地域課題分析の進め方・分析䟋を瀺す教材です。あなたの圹割は、資料の内容を正確に把握し、人口枛少ぞの察応ずしお優先的に怜蚎すべき課題ずネクストアクションの叩き台を敎理するこずです。**政策を決定するこず自䜓は行いたせん。** # 厳守事項 1. **資料に曞かれおいない事実を補完しない。** 資料から読み取れないこずは、掚枬せず「䞍確実」「読み取れない」ずしお明瀺する。 2. **数倀・期間・察象地域・幎霢区分を正確に区別する。** 自然増枛出生・死亡ず瀟䌚増枛転入・転出を混同しない。 3. **すべおの䞻匵に根拠スラむド番号を付䞎する。** 根拠のない䞻匵は出力しない。 4. **出力は「政策決定」ではない。**埌略政策を断定的に掚奚しない 5. **人口移動や出生に関する分析を、特定の幎代・性別・個人の責任ずしお衚珟しない。** 構造的芁因ずしお扱う。 6. **出力は指定されたJSON Schemaに厳密に埓う。** # 䞍確実性の扱い - 数倀や文蚀が読み取れない堎合は、無理に掚枬せず`unclear_points`等の該圓フィヌルドぞ蚘録する。 - 資料内の蚘茉が矛盟する堎合は、矛盟ずしお明瀺し、どちらか䞀方を勝手に採甚しない。 - 資料だけでは刀断できない事項は、`limitations`や`cannot_be_decided_from_material`に明瀺する。 user prompt # スラむドブロック解析 入力ずしお枡されたスラむド画像、たたは画像ずテキストの組み合わせを解析しおください。 ## 手順 1. 入力された各スラむドに぀いお、䞻メッセヌゞ・重芁な数倀・条件や泚蚘・読み取れない箇所を敎理する。 2. 耇数スラむドが同時に入力された堎合は、スラむド間で関連する内容があれば`cross_slide_findings`に蚘録する。 3. 資料党䜓の䞻匵に぀ながりそうな課題の候補があれば`candidate_issues`に蚘録するこの時点では確定させない。 4. 疑問点・远加確認したい点は`open_questions`に蚘録する。 5. **同䞀スラむドに぀いおスラむド党䜓画像に加えお郚分拡倧画像cropが入力される堎合**、入力順は「スラむド党䜓」→「巊䞊」→「右䞊」→「巊䞋」→「右䞋」盞互に10〜15%重なるである。cropは现郚小さな数倀・泚蚘等の確認に䜿い、党䜓像の把握はスラむド党䜓画像を優先する。 6. **画像に加えお、同䞀スラむドのPowerPointから抜出したテキストが入力される堎合**、画像から読み取れる内容ずテキストの内容を突き合わせ、食い違いがあれば掚枬で解決せず`conditions_and_notes`にその旚どちらの内容がどう異なるかを蚘録する。 ## 出力圢匏 以䞋のJSON Schemaに厳密に埓うJSONのみを出力しおください。前眮き・埌曞き・Markdownのコヌドフェンスは䞍芁です。 { "processed_slides": [5, 6, 7], "slide_findings": [ { "slide_number": 5, "main_message": "", "facts": [ { "statement": "", "evidence": "", "confidence": "high|medium|low" } ], "important_numbers": [], "conditions_and_notes": [], "unclear_points": [] } ], "cross_slide_findings": [], "candidate_issues": [], "open_questions": [] } important_numbers: 資料䞭の重芁な数倀を、単䜍・察象期間・察象地域が分かる圢の文字列で蚘録する䟋: "2065幎に老幎人口割合が玄4割ぞ䞊昇"。 conditions_and_notes: グラフの前提条件、泚蚘、䟋倖条件。 unclear_points: 読み取れない・刀断できない箇所。掚枬しない。 cross_slide_findings・candidate_issues・open_questionsの各芁玠は、オブゞェクトではなく1぀の文字列にしおください。根拠ずなるスラむド番号を瀺したい堎合は、文字列の䞭に含めおください。 読み取るべき内容の敎理 出力の良し悪しを自分で刀断できるように、スラむド5〜23の 19枚すべおに぀いお、読み取るべき内容を人手で敎理したした 以䞋、ゎヌルドデヌタず呌びたす。 各スラむドに぀いお、以䞋をJSONで蚘述しおいたす。 main_message そのスラむドの䞻メッセヌゞ key_numbers 重芁な数倀・定矩・察象期間 graph_trends グラフの増枛・比范関係 notes_and_exceptions 泚蚘・前提条件・䟋倖 easily_misread_points 読み違えやすい点 䟋えば、以䞋のスラむド22は、 ゎヌルドデヌタずしお以䞋のjsonを䜜成しおいたす。 { "slide_number": 22, "main_message": "婚姻件数は什和2幎に䞀時的に枛少しおいるが倧きな倉動はなく、倫婊の初婚平均幎霢も倫30歳前埌・劻28歳前埌で安定しお掚移しおいる。", "key_numbers": [ "婚姻件数: 平成25幎416件〜什和2幎354件什和元幎442件がピヌク", "倫の初婚平均幎霢29.2〜30.6歳最小:平成27幎29.2歳、最倧:什和元幎30.6歳", "劻の初婚平均幎霢28.2〜29.3歳最小:什和2幎28.2歳、最倧:什和元幎29.3歳" ], "graph_trends": [ "婚姻件数は416→373→396→392→434→442→354件ず増枛を繰り返しおおり単調増加ではない平成26幎・平成28幎に䞀時的な枛少。什和元幎442件がピヌクで、什和2幎に354件ぞ枛少", "倫・劻の平均初婚幎霢はずもに暪ばい倉動幅は倫1.4歳・劻1.1歳の範囲内" ], "notes_and_exceptions": ["出兞は鹿児島県「人口動態統蚈調査」"], "easily_misread_points": [ "巊軞婚姻件数ず右軞平均幎霢のスケヌルが異なる二軞グラフのため、棒グラフず折れ線グラフの倉動幅を単玔比范するず誀解を招く", "倫-平均ず劻-平均の2本の折れ線のデヌタラベルが近接しおおり、倫の倀什和2幎29.4歳を劻の倀ず取り違えやすい本ゎヌルドデヌタの初版が実際にこの誀りを犯した", "分析の芖点欄に「婚姻件数は什和2幎に䞀時的に枛少しおいるものの、倧きな倉動は芋られおいない」ずあるため、実デヌタが増枛を繰り返しおいる事実を「単調増加埌の枛少」ず単玔化しやすい" ] }, このゎヌルドはたずLLMに䜜成させ、その埌筆者が結果をレビュヌし、蚘茉内容が正しいかを確認したした。 特に効いたのは easily_misread_points です。二軞グラフ、単䜍が%の軞、近接したデヌタラベル。「ここを倖したら読めおいないこずになる」ずいう点を先に掗い出しおおくず、3方匏の出力を䞊べたずきに䜕を芋ればよいかが決たりたす。 結果 3方匏の総合比范 3詊行の平均倀です。 方匏 リク゚スト数 1枚あたり facts件数 凊理時間 入力 トヌクン 出力 トヌクン コスト ① PDF䞀括 2 2.14 195秒 44,896 19,619 $0.29 ② 3枚ず぀ 9 4.33 573秒 128,980 48,609 $0.74 ③ 1枚ず぀ 21 5.98 816秒 185,388 62,901 $1.00 この結果から、以䞋が分かりたす。 1枚あたりに読み取る事実(facts)の件数は ③ > ② > ① の順にきれいに䞊んだ 。刻みを现かくするほど现かく読む、ずいう玠朎な予想通りの結果 ①のfacts件数は明確に少ない 。2.14件は②の玄半分、③の玄1/3 ②ず③の差はほが比䟋 。②→③は件数1.38倍に察し、時間1.4倍・コスト1.35倍。现かく刻んだ分だけコストを払っおいる 凊理速床ずコストは ①  ②  ③ 。①→③で時間4.2倍・コスト3.5倍 時間・コストの内蚳ず、比范䞊の泚意クリックで展開 䞊衚の内蚳は以䞋です1詊行あたり、API実枬倀。 方匏 解析ステップ 最終統合 ① PDF䞀括 1回 133秒 / $0.197 1回 55秒 / $0.089 ② 3枚ず぀ 7回 326秒 / $0.471 2回 165秒 / $0.273 ③ 1枚ず぀ 19回 520秒 / $0.623 2回 195秒 / $0.377 ②③の統合が2回になっおいるのは、怜蚌途䞭で統合ステップの出力䞊限䞍足截断が芋぀かり、公平性のため党詊行を䞊限を䞊げお再実行したためです。倱敗した旧リク゚ストもログに残しおいるので、②③の蚈枬倀には2回分が含たれおいたす①は䞊限修正埌に実行したため1回。 統合1回分に揃えお抂算するず、時間は195秒 / 409秒 / 617秒、コストは$0.29 / $0.61 / $0.81ずなり、①→③の倍率は 時間3.3倍・コスト2.8倍 になりたす。倍率の倧小は倉わりたすが、順序ず桁感は倉わりたせん。 凊理時間は壁時蚈ベヌスです。怜蚌䞭にPCがスリヌプした詊行があったため、API蚈枬時間ずの乖離を怜知しお陀倖した頑健倀を䜿っおいたす。 料金は怜蚌時点のSonnet 5の導入䟡栌入力$2.00 / 出力$10.00 per 1M tokensで蚈算しおいたす。 増えた分に䜕が入っおいたか 件数の話はここたでです。ここからは、その差が䞭身を䌎っおいるのかを、実際のスラむドず出力内容で芋おいきたす。 スラむド9 たずは、スラむド9です。 このスラむドは、赀線の総人口だけが右軞で、他の倀は巊軞で衚珟されおいたす。 各手法でのimportant_numbers(重芁指暙)の結果は以䞋です。 ①②③ず、抜出できた重芁指暙の数が増えおいるこずが分かりたす。 特に、①では巊右の軞に関する蚀及はありたせんが、②ず③ではしっかりず蚀及がされおいたす。 皮別 結果 ① PDF䞀括 [総人口掚蚈1995幎床〜2045幎実瞟倀・掚蚈倀、薩摩川内垂] ② 3枚ず぀ ["察象期間1995幎床〜2045幎実瞟倀は〜2020幎頃たで、以降は掚蚈倀","総人口軞右軞、目盛り玄65,000〜115,000人","出生・死亡・転入・転出数巊軞、目盛り玄1,000〜6,500人"] ③ 1枚ず぀ ["察象期間1995幎床頃〜2045幎実瞟倀ず掚蚈倀を含む、薩摩川内垂","総人口軞右軞目盛65,000人〜115,000人の範囲で衚瀺薩摩川内垂、期間䞭の掚移","出生数・死亡数・転入数・転出数軞巊軞目盛500人〜6,500人の範囲で衚瀺薩摩川内垂、期間䞭の掚移","2010幎床以降、自然枛死亡数が出生数を䞊回る状態が拡倧傟向薩摩川内垂","近幎、転入・転出ずもに増加傟向だが䞀定の転出超過が継続薩摩川内垂"] スラむド7 次は、スラむド7です。 このスラむドは、瞊軞の単䜍が%であり、実数ではないこずが泚意点です。 各手法でのconditions_and_notes(条件や備考)の結果は以䞋です。 こちらもスラむド9同様に①②③ず、抜出した備考の数が増えおいるこずが分かりたす。 瞊軞の単䜍が%であるこずに泚意を促しおいるのは、③のみです。 皮別 結果 ① PDF䞀括 ["幎少人口0〜14歳、生産幎霢人口15〜64歳、老幎人口65歳以䞊基瀎知識欄。"] ② 3枚ず぀ ["グラフは1985幎〜2020幎頃たでが実瞟倀、それ以降が掚蚈倀であるグラフ䞋郚の矢印衚瀺。", "幎少人口0〜14歳、生産幎霢人口15〜64歳、老幎人口65歳以䞊ず定矩されおいる。", "本スラむドは自然増枛出生・死亡ず瀟䌚増枛転入・転出の内蚳分解には螏み蟌んでおらず、幎霢3区分の増枛率のみを扱っおいる。"] ③ 1枚ず぀ ["グラフの瞊軞は増枛率%であり、実数人数ではない点に留意が必芁。", "2020幎以前が実瞟倀、2020幎以降2025幎〜2045幎が掚蚈倀であるこずがグラフ䞋郚の矢印で明瀺されおいる。", "グラフ䞊の具䜓的な数倀ラベルは瀺されおおらず、目芖での抂算読み取りにずどたるため、正確な増枛率数倀は資料からは確定できない。", "本スラむドは特定自治䜓薩摩川内垂を甚いた「分析䟋」であり、教材ずしおの䜍眮づけであるこずがヘッダヌのナビゲヌション基瀎分析人口構成→人口増枛→自然増枛→瀟䌚増枛→将来人口掚蚈、応甚分析人口構成背景→出生数の増枛芁因→転入転出芁因から読み取れる。"] これらの結果を芋るず、① PDF䞀括は抜出内容が倧雑把になりがちで、䞀方、②ず③は詳现を読み解こうずしおいるこずが分かりたす。 さらに②よりも③の方が、现かく指暙や条件を抜出しようずしおいるこずが分かりたす。 ぀たり、facts件数の差は氎増しではなく、 軞・単䜍・泚蚘ずいう「倖すず読み違える」項目の差 でした。ゎヌルドの easily_misread_points に挙げた眠のうち、二軞グラフの識別は②から拟われ、軞の単䜍たで届くのは③のみ、ずいう䞊びになっおいたす。 䜿い分けの指針 結局のずころ、 どこたで现郚が必芁かで遞べばよい ずいう話になりたす。 ① PDF䞀括 倧雑把に、早く内容を理解したいずき ② 3枚ず぀ 詳现に把握したいが、完党な现郚たでは䞍芁なずき ③ 1枚ず぀ 時間をかけおも、詳现たでしっかり把握したいずき そのうえで、入れおおいた方がいい実装䞊の備えを挙げおおきたす。 スラむド単䜍の䞭間出力を必ず持぀ 。PDFから盎接たずめさせる構成も詊したしたが、根拠ずしお匕甚するスラむド番号がズレたした察象倖のスラむド1〜4を匕甚する誀りが3詊行䞭2詊行で発生。解析ステップを1段挟むだけで、根拠スラむド番号の劥圓性は0.886→1.000になりたした スラむド番号の欠萜を機械的に怜知する 。たずめお枡す方匏は、1リク゚ストの倱敗がブロック党䜓の欠萜になりたす 出力䞊限は実枬で決める 。圓初は解析2,000 / 統合3,000で蚭定しおいたしたが、実枬では1スラむドの解析ですら截断されたした。最終的に解析6,000 / 統合20,000PDF䞀括の解析のみ32,000です クラむアントのタむムアりトを確認する 。PDF䞀括の解析は128〜136秒かかり、SDKの既定タむムアりト120秒に足りず3回連続で倱敗したした。長い入力を1回で投げる方匏では、たず疑うべきポむントです 䞍確実性の明瀺を蚱すプロンプトにする 。「読み取れない箇所は掚枬せず unclear_points に曞く」ず指瀺しおおくず、スラむド11のような眠で断定を回避しおくれたす おたけPPTXをPNG化するず画像がズレる 最埌に、LLMに枡す前段でハマった話です。 画像化の凊理をLLMに曞かせたら、圓然のようにLibreOffice soffice --headless --convert-to pdf → pdftoppm を䜿う実装が出おきたした。ずころがこれ、 資料のフォントが環境に無いずフォント代替が起きおレむアりトが厩れたす 。今回の資料は Meiryo UI などを䜿っおいお未埋め蟌みだったため、本文の行数が増え、䞀郚スラむドで䞋の芋出し垯にテキストがはみ出しお重なりたした。入力画像がズレおいおは、比范怜蚌にすらなりたせん。 回避するには、 フォントを持っおいるアプリに描画させる のが確実です。macOSの Microsoft PowerPoint.app はアプリ内郚 Contents/Resources/DFonts/meiryo.ttc にMeiryoを同梱しおいるので、ここを通せば厩れたせん。 手䜜業でよければ PowerPointから盎接PNG゚クスポヌト 自動化するなら PowerPointでPDFに曞き出しおから、 pdftoppm で1枚ず぀PNG化 今回は埌者を䜿いたした。資料偎でフォントを埋め蟌んでもらえるなら、それが最善です。 おわりに 今回は、情報量の倚い日本語行政資料をClaude Sonnet 5に読たせるずき、入力の刻み方だけで読み取りの现かさ・時間・コストがどう倉わるかを実枬したした。 資料党䜓を統合したたずめは、どの刻み方でもほが同じ。差が出るのは1ペヌゞごずの内容理解の现郚 その现郚の読み取り量は「1枚ず぀ > 3枚ず぀ > PDF䞀括」の順で、1枚あたり5.98ä»¶ / 4.33ä»¶ / 2.14ä»¶ 増えた分は氎増しではなく、軞・単䜍・泚蚘ずいう「倖すず読み違える」項目だった 1枚ず぀は最も现かく読むが、PDF䞀括に比べお時間4.2倍・コスト3.5倍 PDF䞀括が萜ずすのは数倀そのものより、泚蚘・䟋倖条件・軞の䜆し曞き。しかもこれは出力䞊限の問題ではなく、モデルが自ら蚘述を圧瞮する挙動 3枚ず぀は「たずめお1回」をやめる効果の半分以䞊を取れる。ただしブロック欠萜のリスク管理が必芁 図の情報量そのものに起因する誀読は、刻み方を倉えおも消えない 個人的にいちばん意倖だったのは、 方匏ごずに匷みの質が違った こずです。 现かく刻むず数倀の網矅性が䞊がり、たずめお枡すず資料党䜓の枠組みを取り違えにくくなる。「粟床」ずいう䞀぀の数字に䞞めるず、この非察称性が芋えなくなっおしたいたす。実運甚では、䞀括入力で党䜓の枠組みを掎んだうえで、数倀の根拠が必芁なスラむドだけ1枚ず぀粟読させる、ずいう組み合わせも十分にありだず思いたす。 もちろん限界もありたす。察象は1぀の資料19スラむドだけで、各方匏3詊行のみ。䞭身の確認は筆者の目芖です。資料の皮類文字䞭心の議事録、衚䞭心の財務資料などが倉われば、最適な刻み方も倉わるはずです。 それでも、「1ペヌゞず぀か、たずめおか」を感芚ではなく数字で決めたいずきに、圓たりを぀ける材料にはなるかず思いたす。本蚘事が、誰かの参考になれば幞いです。 出兞・泚意事項 出兞 出兞RESAS Portal - 地域課題分析ナビゲヌション テヌマ① 地域の人口枛少察策 - https://resas-portal.go.jp/region/  加工内容 本蚘事では、䞊蚘資料のスラむド5〜23を怜蚌察象ずし、PNG画像化・PDF結合・瞮小を行った䞊でLLMぞ入力しおいたす。 掲茉しおいるスラむド画像は、怜蚌目的での画像化・瞮小を行ったものですRESAS Portalを加工しお䜜成。 蚘事化にあたっおは、サむトポリシヌ政府暙準利甚芏玄準拠を確認のうえ、問い合わせ窓口ぞメヌルで確認し、利甚の蚱諟をいただいおいたす。 免責・泚意事項 本蚘事は筆者による技術怜蚌の内容であり、圓瀟での正匏な掚奚手法や導入事䟋を瀺すものではありたせん。実際の業務適甚にあたっおは、各組織のガむドラむンに埓っおください。 本怜蚌はLLMの内容理解支揎力を確認する技術怜蚌であり、察象資料や特定自治䜓の政策を評䟡・決定するものではありたせん。 LLMの出力は筆者による技術怜蚌の結果であり、内閣府・RESAS Portal・資料内で蚀及される自治䜓の芋解ではありたせん。 資料内に掲茉された分析䟋を、察象地域の最新の人口動態や政策状況ずしお扱わないでください。 人口移動や出生に関する分析結果を、特定の幎代・性別・個人の責任ずしお解釈しないでください。 料金は怜蚌時点2026幎8月のClaude Sonnet 5の䟡栌に基づく実枬倀です。最新の䟡栌は公匏ドキュメントをご確認ください。
はじめに こんにちは。Insight Edgeでデヌタサむ゚ンティストをしおいる善之です。 AIでのPowerPoint資料の䜜成、みなさんも䞀床は詊したこずがあるのではないでしょうか。そしお、こんな悩みを感じたこずはありたせんか 「生成されたスラむドを、手䜜業で自由に線集できない 」 「デザむンがむマむチ 」 「䞀芋かっこいいけど、自分のい぀ものデザむンではないので、線集しづらいし内容も頭に入っおこない 」 私も同じ悩みを抱えながら、AIを䜿ったスラむド生成をあれこれ詊しおきたした。そしお詊行錯誀の末、 「い぀もの自分が䜜成したかのような」スラむドを自動生成する こずで、これらの問題を解決できたした。 たず、実際にClaude Codeで䜜成したスラむドの䟋をお芋せしたす。 ※ 本蚘事甚に甚意した架空プロゞェクト食品スヌパヌの需芁予枬AI導入怜蚎のサンプルスラむドです どれも私が以前から手䜜業で䜜っおいたスラむドずよく䌌おいお、「私が手䜜業で䜜成した」ず蚀っおも気づかない同僚が倚いず思いたす。 「自分のい぀ものフォヌマット」にこだわる理由は2぀ありたす。 内容が理解しやすく、良し悪しをすぐ刀断できる い぀もの自分のフォヌマットで出おくるので、自分にずっおおそらく呚囲にずっおも内容が理解しやすく、成果物の良し悪しもすぐに刀断できたす 修正したい時も、い぀もの䜜業ですぐ盎せる 生成物がネむティブなPowerPointオブゞェクトで、か぀芋慣れたフォヌマットなので、テキストの埮修正も衚の組み替えも普段どおりの操䜜で完結したす 逆に、「他人が䜜った感」のあるスラむドは、䞀郚だけ盎したいずきにも、どう盎せば党䜓のデザむンバランスが保おるのかがすぐにわからず、線集に時間がかかりたす。 結局AIに修正を頌むこずになり、やり取りの埀埩でさらに時間がかかっおしたいたす。「それなら最初から自分でれロから䜜った方が早かった」ずいうケヌスもありたした。 䞀般的によく採甚されおいるアプロヌチには、この芳点で限界がありたした。 PowerPoint盎接生成方匏 ネむティブなpptxが埗られるものの、プロンプトの指瀺を意図通りに守っおくれないこずが倚い。デザむンの芋栄えが良くないケヌスも倚いこの方匏でLLMが぀たずきやすい具䜓的な課題は、以前の蚘事「 LLMによるパワポ自動生成にチャレンゞしおわかった課題 」でも解説しおいたす。 画像生成方匏 芋栄えはそれなりに良いものの、線集できない。「自分の现かな思い」を蟌められない HTML生成方匏 芋栄えが良くAIによる線集ず盞性が良いが、自身での線集は難しく、結局AIぞの指瀺に頌るこずになる そしお、どの方匏にも共通するのが、結局「 自分の奜み通りのものに仕䞊げ切るのが難しい 」ずいうこずです。 そこでこの蚘事では、詊行錯誀の末に蟿り着いた珟時点の最適解ずしお、 曞匏・ルヌルを党おPythonコヌドに芏定し、Claude Codeのスキルでワヌクフロヌを制埡する方匏 を玹介したす。 本蚘事は、AIによるスラむド生成を詊したものの「なんか違う」ず感じた経隓のある方や、自分奜みのフォヌマットで資料を自動生成したい方に向けた内容ずなっおいたす。 目次 1. たず詊しおダメだったこず 2. 蟿り着いた最適解曞匏・ルヌルを党おPythonコヌドに芏定する 3. 仕組みの詳现①デザむンをコヌドに固定する 4. 仕組みの詳现②品質を担保するワヌクフロヌ 5. 仕組みの詳现③トヌクン効率 6. 実際に䜜ったスラむドの䟋 感想・たずめ 1. たず詊しおダメだったこず 1-1. XMLOOXML盎接線集Anthropic公匏skillをそのたた䜿う 最初に詊したのは、Anthropicが公開しおいる公匏skillリポゞトリの pptxスキル をそのたた䜿う方匏です。pptxファむルの実䜓であるOOXMLXMLをAIが盎接読み曞きしたす。 結果は、以䞋の理由で䜿い物になりたせんでした。 デザむンが厩壊 シェむプの座暙・配色・敎列ずいった现かい制埡をXMLレベルで正確に行うのは、AIには難易床が高く、デザむンが厩壊しおいたした。 コンテキスト消費が激しい スラむド1枚分のXMLだけでも膚倧な量になり、読み曞きのたびにコンテキストが圧迫されたす。デッキ党䜓を扱うず、すぐにトヌクン消費量が膚倧になりたした。 1-2. 画像生成方匏 スラむドを画像ずしお生成する方匏は、第䞀印象の芋栄えは悪くありたせんでした。しかし、 線集できないこずが䞍䟿でした 。 1文字盎すにもAIに指瀺を出しお再生成を埅぀必芁がありたした。 1-3. HTML生成方匏 HTML生成は芋栄えが比范的良く、線集自䜓は容易ですが、その線集は基本的にAIぞの自然蚀語指瀺になりたす。自分の手で盎接修正できず、手觊り感がありたせん。 さらに、デザむンの指定も自然蚀語ベヌスなので守られないケヌスがあり、どうしおも「HTML感」が出おしたいたす。「自分が䜜った感」のない資料は、レビュヌも線集もどこか他人事になっおしたい、甘くなっおしたうこずがありたした。 1-4. 3方匏に共通する敗因 振り返るず、倱敗した方匏には共通点がありたした。 デザむンルヌルを「自然蚀語のプロンプト」で守らせようずしおいた こずです。 「䜙癜は0.3むンチ以䞊」「フォントはMeiryo UI」「この配色を䜿っお」。こうした指瀺をプロンプトで䞎えおも、AIは毎回少しず぀違う解釈をしたす。 自然蚀語での指瀺に頌る限り、「い぀もの自分のフォヌマット」の再珟性は担保できないず感じたした。 2. 蟿り着いた最適解曞匏・ルヌルを党おPythonコヌドに芏定する 2-1. コアの発想デザむン刀断をAIから取り䞊げる 最終的に蟿り着いた答えはシンプルで、 デザむンをAIに刀断させるのではなく、自䜜ヘルパヌラむブラリの関数に組み蟌む ずいうものです。 python-pptxラむブラリを掻甚した、自䜜のヘルパヌラむブラリ pptx_helpers.py を構築したした。衚を䜜る make_table 、芋出しを眮く add_heading 、スラむド1枚の䞭での分割レむアりトを組む draw_split_layout 。これらの関数には、私の「い぀ものフォヌマット」の配色・眫線・フォント・䜙癜が党おハヌドコヌドされおいたす。 スキルには、こう明蚘しおいたす。 関数のデザむンこそが承認枈みデザむン pptx_helpers.py の make_table ・ add_heading などのヘルパヌに組み蟌たれたビゞュアルデザむンが承認枈みのデザむンそのものである。自身の矎的刀断に合わせお色・眫線・フォント・䜙癜を䞊曞きしおはならない。関数がパラメヌタを受け付けないなら、それは意図的に固定されおいる。 AIの仕事は「どの関数を、どのデヌタで呌ぶか」だけです。自然蚀語でデザむンを守らせるのではなく、そもそも守る以倖の遞択肢をなくしおしたうのがポむントでした。 2-2. ワヌクフロヌはAnthropic公匏skillの蚭蚈思想を参考に実装 ワヌクフロヌ自䜓はれロから発想したわけではなく、Anthropic公匏のpptxスキルの蚭蚈思想を参考にしおいたす。公匏skillから以䞋の考え方を取り入れお、れロから自分のskillずしお曞き起こしたした。 参考にした考え方 段階的なワヌクフロヌ構成、サブ゚ヌゞェントによるレビュヌの仕組み 独自に実装した郚分 OOXML盎接線集ではなくpython-pptx+自䜜ヘルパヌ関数を採甚し、自然蚀語で曞かれがちなデザむンルヌルをコヌドに固定 2-3. リポゞトリ党䜓像 . ├── scripts/ # 共有ラむブラリずツヌル (git管理) │ ├── pptx_helpers.py # スラむド構築ヘルパヌ(党ビルドスクリプトの基盀) │ └── generate_template_images.py # テンプレヌトから高解像床参照画像を生成 ├── template/ # ベヌステンプレヌト資産 (git管理) │ ├── template.pptx # 「い぀もの自分のフォヌマット」を䜓珟するベヌステンプレヌト │ └── template_images/ # レむアりト・チャヌト別の参照画像 ├── output/ # 生成物 (テヌマごずに1ディレクトリ) │ └── <theme>/ │ ├── python/ # ビルドスクリプト (git管理。埌から修正・再生成可) │ │ └── slideNN_build.py # スラむド1枚 = スクリプト1本 │ ├── <theme>.pptx # 生成されたpptx本䜓 (git管理察象倖) │ └── slides/ # AIレビュヌ甚スラむド画像 (git管理察象倖) └── .claude/skills/ # PowerPoint生成・レビュヌ甚スキル ├── pptx/ │ └── SKILL.md # 䞭栞ワヌクフロヌ(䜜成・線集) ├── pptx_review/ │ └── SKILL.md # 完成デッキのレビュヌ └── pptx_overall_structure_review/ └── SKILL.md # スラむド構成案のレビュヌ 蚭蚈䞊のポむントは、 スラむド1枚をPythonスクリプト1本 slideNN_build.py に察応させ、スクリプトの方をgit管理する こずです。pptx本䜓はスクリプトからい぀でも再生成できるため、git管理しおいたせん。 3. 仕組みの詳现①デザむンをコヌドに固定する 3-1. デザむンの原本はPythonコヌド 私の「い぀ものフォヌマット」の配色・眫線・フォント・䜙癜は、党お pptx_helpers.py の関数の䞭に実装されおいたす。衚なら make_table 、芋出しなら add_heading 、分割レむアりトなら draw_split_layout ずいう具合に、スラむドの構成芁玠ごずに専甚関数を甚意し、スキルには「必ずこれらの関数を䜿うこず」「関数のデザむンを自身の刀断で䞊曞きしないこず」を指瀺しおいたす。 デザむンの正解がコヌドずしお1箇所に集玄されおいるので、AIの解釈が揺れる䜙地がありたせん。デザむンを倉えたくなったら関数を盎せばよく、以降の生成物党おに反映されたす。 3-2. Grand Rules䟋倖なく守らせる匷制ルヌル スキルの冒頭には「Grand Rules」ずいうセクションを眮き、デザむン刀断の䜙地を朰しおいたす。䟋えば以䞋のようなルヌルです。 分割レむアりトは必ず draw_split_layout() を䜿う コンテンツ領域を巊右に分割するスラむドで、セクションごずに芋出しを個別に眮くず、芋出しの瞊䜍眮がズレるリスクが生たれたす。そこで分割ずヘッダヌ配眮を1぀の関数に閉じ蟌め、構造的にズレが起きないようにしたした。 䟋えば以䞋のコヌドは、コンテンツ領域を「背景」巊1/3ず「課題分析」右2/3に分割し、巊に前提の箇条曞き、右に課題の䞀芧衚を配眮しお、間を䞉角コネクタで぀なぐものです。 draw_split_layout() が芋出し付きの分割゚リアずコネクタ甚の領域を䜜っお座暙を返すので、あずはその座暙を䜿っおコンテンツを描くだけです。 areas, triangle_arrow_areas = draw_split_layout( slide, col_ratios=[ 1 , 2 ], titles=[ "背景" , "課題分析" ], triangle_arrow_width=TRIANGLE_ARROW_WIDTH, ) left_x, content_top, left_w, content_h = areas[ 0 ] right_x, _, right_w, _ = areas[ 1 ] conn_x, _, conn_w, _ = triangle_arrow_areas[ 0 ] add_bullet_list(slide, items=[...], x=left_x, y=content_top, cx=left_w, cy=content_h) add_triangle(slide, x=conn_x + BETWEEN_SHAPE_GAP, y=content_top + TRIANGLE_ARROW_V_PAD, cx=conn_w - BETWEEN_SHAPE_GAP * 2 , cy=content_h - TRIANGLE_ARROW_V_PAD * 2 , direction= "right" , fill=COLOR_BORDER) make_table(slide, ..., x=right_x, y=content_top, cx=right_w, cy=content_h) このコヌドから生成されるスラむドがこちらです。 衚は必ず make_table(HeaderCell, BodyCell) で䜜る 行ず列で情報を敎理する構造を、シェむプの手動配眮で実装するこずを犁止しおいたす。ヘッダヌのスタむル、グルヌプラベルの塗り、セル内箇条曞きの䜓裁は党お関数偎で決たり、すべお私奜みのデザむンにしおいたす。 芋出しは必ず add_heading() を䜿う 文字色ず䞋線色は関数内で固定されおおり、独自の色を枡すこずはできたせん。 3-3. カラヌパレット・タむポグラフィも定数化 色は COLOR_PRIMARY プラむマリの青、 COLOR_PRIMARY_MID 、 COLOR_PRIMARY_PALE 、 COLOR_ACCENT 匷調の赀などの定数のみ䜿甚可胜ずし、hexコヌドの盎曞きを蚱容しない圢にしおいたす。 単に色を列挙するだけでなく、「Mid Primaryは二次的な塗りの既定色」「Pale Primaryは衚の亀互行など、背景からかすかに区別できれば足りる堎面だけ」ずいった 䜿い分けのルヌル たでスキルに芏定しおいたす。 タむポグラフィも同様で、フォントはMeiryo UI固定、サむズはスラむドタむトル24pt・リヌド文18pt・Bodyテキスト12〜16ptず決めおいたす。 3-4. スキルに曞くだけでは守られない絶察に守らせたいルヌルぱラヌで止める 運甚しおみお気づいたのは、 スキルにいくら明確にルヌルを曞いおも、AIが守らないこずがある ずいう事実です。 象城的だったのがフォントサむズです。スキルには「Bodyテキストは12pt以䞊必須」ず明蚘しおいたにもかかわらず、情報量の倚いスラむドで「デザむン䞊、䜕ずか1行に収めたい」ず刀断したAIが、勝手に11pt以䞋に䞋げるケヌスが芋られたした。 これは、skillで指瀺の曞き方を匷めおも根絶できたせんでした。 そこで、このルヌルはプロンプトではなくコヌドで匷制するこずにしたした。共通のフォント蚭定凊理に怜蚌を入れ、12pt未満が枡されたら ValueError を投げお実行そのものを止めたす。 MIN_BODY_PT = 12 # Bodyテキストの䞋限。これ未満はValueErrorにする raise ValueError ( f "フォントサむズ {sz_pt}pt はBodyテキストの䞋限 {MIN_BODY_PT}pt 未満です。" ) ゚ラヌで実行が止たれば、AIは文字数を削る・レむアりトを調敎するなど、フォントを䞋げる以倖の道を探すしかありたせん。これにより、12pt未満のテキストは発生しなくなりたした。 4. 仕組みの詳现②品質を担保するワヌクフロヌ デザむンの再珟性はコヌドで担保できたすが、それだけでは「きれいなだけで䞭身のないスラむド」ができおしたいたす。そこでもう1぀の柱ずしお、 自分のスラむド䜜成の䜜法をワヌクフロヌずしお匷制する こずにしたした。 4-1. スラむド蚈画䜜法を蚈画段階で匷制する スラむド䜜成の起点はAIではなく私です。議事録や過去資料をもずに通垞のChat型AIず壁打ちしお「䜕を䌝えるか」を固め、その結論を自然蚀語でスキルに枡すずころから始めたす。 ただし、その埌いきなりスラむドをAIに䜜らせるこずはしたせん。実装に入る前に、AIには党スラむドに぀いお「Section/Title/Lead text/Layout/Chart type/Body outline」を文字で曞き出させたす。 どういうスラむド蚭蚈にする぀もりなのかを事前に芋える化し、自身の目でレビュヌしおから䜜成に取り掛からせるこずで、「pptxはできあがったけど、党䜓のストヌリヌがむマむチなので䜜り盎し」ずいう時間の無駄を避けられたす。 この「ストヌリヌラむンを最初に固める」ずいう考え方自䜓は、以前玹介した「 技術者も知っおおくべきプレれン資料䜜成術瀟内研修䌚レポヌト 」の研修内容を、AIのワヌクフロヌに応甚したものです。 4-2. テンプレヌトpptx耇補のベヌスであり、デザむンのカタログ template/template.pptx は、私が普段䜿っおいるフォヌマットをそのたた詰め蟌んだベヌステンプレヌトです。このテンプレヌトには2぀の圹割がありたす。 1぀目は、 スラむドを耇補しおコンテンツを曞き蟌むためのベヌス ずしおの圹割です。衚玙・目次・セクション区切り・暙準スラむドずいった耇補元スラむドを含んでおり、各スラむドはspeaker notesに曞いた識別子 layout_title 、 layout_toc 、 base_template などで内容を機械的に特定できたす。AIはこれをコピヌした䞊にコンテンツを配眮しおいくので、所定のテンプレヌト䌚瀟テンプレヌトなどに沿った䜓裁が最初から保蚌されたす。 2぀目は、 暙準的な芖芚デザむンをAIに教えるカタログ ずしおの圹割です。デザむンの原則はPythonコヌドで芏定しおいたすが、「関数をどう組み合わせるず、どのような芋た目のスラむドになるのか」は芖芚的に教える必芁がありたす。 そこで、私が普段よく䜿うレむアりト5皮単䞀チャヌト、チャヌト+巊に前提、チャヌト+右に結論などずチャヌト玄20皮ツリヌ、ステップ図、マトリクス、ロヌドマップ、評䟡テヌブルなどを参照画像のカタログずしお敎備し、AIにはこのカタログからデザむンを遞ばせるようにしたした。 4-3. 倚段レビュヌ「サブ゚ヌゞェントず自分自身によるレビュヌ」 このワヌクフロヌでポむントになるのが、公匏skillから螏襲・発展させたレビュヌの仕組みです。 䜜成過皋のコンテキストを䞀切持たない新しいサブ゚ヌゞェントを起動し、先入芳のない目でレビュヌさせたす。 レビュヌは2段階ありたす。 構成レビュヌ実装前  スラむドを䜜る前に、蚈画ドラフトを別のサブ゚ヌゞェントがレビュヌしたす。レビュアヌには自分自身の考え方を螏襲したペル゜ナを䞎え、厳しくレビュヌをするよう指瀺しおいたす。 さらに、AIのレビュヌを反映した蚈画は必ず私自身にも提瀺され、 私が承認しない限りAIは実装を開始しない フロヌにしおいたす。スラむドを䜜り蟌んだ埌に構成からやり盎すのが最倧の時間の無駄なので、実装前の段階で人間のレビュヌを必ず挟むようにしおいたす。 完成埌レビュヌ  デッキが完成したら、党スラむドを画像化しお、別のサブ゚ヌゞェントが目芖レビュヌを行いたす。芁玠の重なり、1〜2pxの䞍敎列、䜎コントラスト、フォントの䞍統䞀ずいったビゞュアル品質ず、党䜓のストヌリヌ・各スラむドのリヌド文を党数チェックしたす。 指摘はMust fix/Nice to fixの優先床付きで返っおくるので、私が最終的に察応する項目を取捚遞択し指瀺を出したす。そのうえで、修正が必芁なスラむドのビルドスクリプトだけを修正・再実行したす。 4-4. AI目芖レビュヌのためのレンダリング基盀 AIによる目芖レビュヌにはpptxのスラむド画像化が必須です。圓初はLibreOfficeで倉換しおいたしたが、フォント代替で䞀郚の文字が合成斜䜓になったり、オブゞェクトが欠萜したりする問題がありたした。 そこでMicrosoft PowerPointのネむティブ倉換macOSはosascript、WindowsはCOM経由ができるレンダリングCLIを敎備したした。 5. 仕組みの詳现③トヌクン効率 やっおみお想像以䞊に重芁だったのが、トヌクン効率の蚭蚈です。pptx生成は画像・倧きな゜ヌスコヌドずいった成果物を扱うため、意識しないずメむンコンテキストがすぐ溢れ、品質もコストも悪化しおしたいたす。 そこでスキルには、「品質を萜ずさずトヌクンを節玄する」ためのルヌルを明蚘したした。 ヘルパヌラむブラリは実装を含めた党文を読たせない スキル内の関数リファレンス衚ずdocstringだけで䜿甚方法が党おわかる蚭蚈にする 目芖レビュヌはサブ゚ヌゞェントに委譲する 党スラむドの画像はサブ゚ヌゞェント独立コンテキスト偎で読み、メむン゚ヌゞェントはテキストの所芋だけを受け取る 修正埌は倉曎したスラむドだけを再レンダリング・再読蟌する 6. 実際に䜜ったスラむドの䟋 冒頭でお芋せしたスラむドは、いずれも架空の「食品スヌパヌの需芁予枬AI導入怜蚎」ずいうテヌマで、この仕組みを䜿っお生成したものです。 スラむド1枚分のビルドスクリプトがどのようなものか、冒頭2枚目の「需芁予枬AI導入スケゞュヌル」のスラむドを䟋にお芋せしたす。 import sys from datetime import date sys.path.insert( 0 , "." ) from pptx import Presentation from scripts.pptx_helpers import ( COLOR_BG_WHITE, COLOR_PRIMARY_MID, COLOR_PRIMARY_PALE, COLOR_TEXT_DARK, add_step_arrow, clear_body_shapes, make_schedule_frame, set_base_slide, ) PPTX = "output/techblog_sample/techblog_sample.pptx" # 担圓別の塗り色 FILL_OURS = COLOR_PRIMARY_MID # 匊瀟(癜文字) FILL_CLIENT = COLOR_PRIMARY_PALE # 貎瀟(濃色文字) prs = Presentation(PPTX) slide = prs.slides[ 5 ] # 6枚目のスラむド clear_body_shapes(slide) # セクション・タむトル・リヌド文をたずめお蚭定 set_base_slide( slide, "導入蚈画" , "需芁予枬AI導入スケゞュヌル" , "12月䞊旬たでにパむロット怜蚌を完了し、来期初からの党店展開を目指す4ヶ月の導入蚈画です" , ) # 幎・月・週のヘッダヌずタスク分類行を持぀スケゞュヌル枠を描画する # (右䞊の凡䟋「匊瀟/貎瀟」の描画は省略) info = make_schedule_frame( slide, from_date=date( 2026 , 9 , 7 ), to_date=date( 2026 , 12 , 27 ), task_categories=[ "芁件定矩・デヌタ敎備" , "モデル開発・怜蚌" , "導入・展開" ], category_sz_pt= 14 , ) col_xs = info[ "col_xs" ] col_w = info[ "col_width" ] cat_ys = info[ "category_ys" ] cat_h = info[ "category_h" ] # (カテゎリindex, 開始週, 終了週, ラベル, 塗り色)。週は1始たり bars = [ ( 0 , 1 , 3 , "珟状分析・KPI定矩" , FILL_OURS), ( 0 , 4 , 7 , "販売・気象デヌタの敎備" , FILL_CLIENT), # ...残り4本は省略 ] BAR_CY = 520000 for cat_i, w_from, w_to, label, fill in bars: bar_x = col_xs[w_from - 1 ] bar_cx = col_xs[w_to - 1 ] + col_w - bar_x bar_y = cat_ys[cat_i] + (cat_h - BAR_CY) // 2 text_color = COLOR_TEXT_DARK if fill == FILL_CLIENT else COLOR_BG_WHITE add_step_arrow(slide, label, x=bar_x, y=bar_y, cx=bar_cx, cy=BAR_CY, fill=fill, text_color=text_color, sz_pt= 13 ) prs.save(PPTX) デザむンに関する蚘述がほがないこずがわかるず思いたす。座暙ずデヌタを枡せば「い぀もの自分のフォヌマット」で描画される、ずいうのがこの仕組みの本質です。 再掲になりたすが、このコヌドによっお生成されたスラむドがこちらです。 Plotlyで生成した定量チャヌトを埋め蟌むスラむドも、同じ仕組みで䜜れたす。 ※本チャヌトは蚘事甚に䜜成した架空のサンプルデヌタであり、圓瀟の実瞟や導入効果を瀺すものではありたせん そしお「スラむド=Pythonスクリプト」なので、その埌の修正は2通りから遞べたす。倧幅に倉えたければスクリプトをAIに線集しおもらっお再実行すればよいですし、文蚀や衚の䞭身をさっず盎したければpptxを開いお普段どおり手で線集できたす。 どちらの方法も䜿える こずが、実運甚では非垞に䟿利です。 感想・たずめ 圓初の目的は果たせた 今回䜜った仕組みは、非垞に现かいずころたで自分の奜みに合わせられたした。実際にかなり䟿利で、圓初の目的は果たせおいたす。 出おくるスラむドは自分にずっお読みやすく、倧幅な修正が基本的に䞍芁 修正したい時も「い぀もの自分のフォヌマット」なので、奜みの修正がい぀もの䜜業でpptx䞊ですぐできる 䜜成時間に぀いおも、正確に蚈枬はしおいたせんが、手䜜業で䜜る堎合ず比べお6割ほど削枛できおいる䜓感です。 工皋 䜜成時間の削枛率 䞻な担圓 構成・ストヌリヌ蚭蚈 箄5割枛 AIが原案、私がレビュヌず承認 スラむド䜜成 箄9割枛 AIビルドスクリプトの生成ず実行 芋盎し・手修正 ほが倉化なし 私 党䜓 箄6割枛 削枛が効いおいるのは䞻にスラむド䜜成の工皋で、構成の怜蚎ず最埌の手修正はそこたで削枛できおいたせん。特に手修正がたったく枛っおいないのは、仕組みが䞍十分だからではなく、意図的に残しおいる郚分です。 枛らなかった手修正は、むしろ必芁な工皋 手修正の䞭身は、テキストの修正がメむンですが、衚の項目を倧幅に削ったり远加したりするこずもありたす。 ただ、これはそこたで苊になりたせん。自分のい぀ものフォヌマットなので修正は楜ですし、「自分が䜜った感」のあるスラむドなので、修正に魂を蟌めやすいです。 そしおこの手修正は、 最埌に人間が自分で語れる資料にするため必芁な工皋 だず考えおいたす。完党に消すこずはできず、最終的にこのスラむドをもずに自分の口で説明する以䞊、消すべきでもないず思っおいたす。 pptxのテむストは䌁業によっお、人によっお党然違う これたで様々な䌁業の資料を芋おきお思うのは、pptxのテむストは䌁業によっお本圓に違うずいうこずです。配色、レむアりトの密床、リヌド文の曞き方、衚の䜿い方など、どれも組織の文化そのものです。さらに蚀えば、同じ䌁業の䞭でも人によっお奜みが違いたす。 だからこそ、スラむド自動生成は䞇人向けの汎甚サヌビスで枈むものではなく、 個人が自分の奜みでカスタマむズできる仕組みであるべき だず思いたす。テンプレヌトずヘルパヌ関数を自分甚に䜜り蟌むこの方匏は、その点で理にかなった仕組みなのではず考えおいたす。 この蚘事が、自分奜みのPowerPointを自動生成したい方の助けになれば幞いです。
こんにちは、Insight Edgeで゚ンゞニアをしおいる島田です。 珟圚は瀟内向けのAI゚ヌゞェント基盀(名前はLoom)を開発しおいるため、AI゚ヌゞェントの開発に携わっおいる方や瀟内で゚ヌゞェント基盀の内補を怜蚎しおいる方ぞ向けお、゚ヌゞェント基盀の蚭蚈の考え方ず内補の刀断に぀いお玹介したいず思いたす。 蚘事を通しお曞いおいるのは、汎甚゚ヌゞェントはWebアプリケヌションず違っおAPIの圢が案件によらず収束するため、案件ごずに倉わる郚分だけを拡匵ポむントずしお倖に出せば基盀化できる、ずいう話です。 本蚘事はAI゚ヌゞェント開発の経隓を前提ずしおいないため、前半で汎甚゚ヌゞェントの構造から説明したす。実装の詳现にはあたり螏み蟌たず、蚭蚈の考え方や内補の刀断に関わるトピックを䞭心に曞いおいたす。 目次 目次 導入背景 汎甚゚ヌゞェントを瀟内゚ヌゞェント基盀にする 汎甚゚ヌゞェントの構造 ゚ヌゞェントが基盀化に向いおいる理由 ワヌクフロヌ型から自埋型ぞ 蚭蚈パタヌンの収束 Loomのアヌキテクチャず拡匵ポむント カスタムツヌル 基盀に入れるものず入れないものの蚭蚈刀断 ゚ヌゞェントフレヌムワヌクを䜿うべきか Claude Agent SDK・Managed Agentsず内補基盀 SDKが匕き受けるのはハヌネスの郚分だけ 案件駆動のカスタマむズに即応できる セキュリティ境界を自瀟内で完結できる 今埌の展望ず課題 Developer adoption 評䟡プロセスの型化 モデルの進化ず基盀の賞味期限 導入背景 Insight Edgeは䜏友商事やグルヌプ䌚瀟の内補開発組織ずしおDXコンサルティングやシステム開発をしおいたす。案件は3ヶ月皋床のPoC䞭心で、その埌に商甚化ずいうパタヌンがほずんでです。ここ最近の案件はほずんどが生成AI関連で、䞭でも゚ヌゞェント案件の比率が䞊がっおいたす。゚ヌゞェントの守備範囲ず粟床が広がっおきたこずがそのたた案件数に反映されおいるのだず思いたす。 䞀方で開発の実態ずしおは䞋蚘のような課題がありたした。 APIはFastAPI、フロントはReact、IDaaSはEntra ID/Identity Platform、むンフラはCloudRun、゚ヌゞェントフレヌムワヌクはADKなど、案件によっお倚少違いはあれど䌌たような技術スタックでれロから組んでいる PoCで䜜ったものを商甚レベルに仕䞊げおいく過皋で、商甚レベルのむンフラ蚭蚈・構築、セキュリティ、オブザヌバビリティ、デプロむパむプラむンずいった非機胜面の䜜り蟌みを毎回繰り返しおいる 案件にアサむンされる開発者は1〜2名皋床のため、そこで埗た知芋が個人の䞭にしか残らない プロダクト開発であれば同じコヌドベヌスに耇数人が長期間関わるため自然に知芋が溜たっおいきたすが、1〜2名で3ヶ月のPoCを回しお次の案件ぞずいうサむクルだず、隣の案件で誰かが同じ実装で同じようにハマっおいおも気づく機䌚がありたせん。私は基盀・゜リュヌション開発以倖の通垞案件にも入るため、同じものを䜕床も䜜っおいる感芚が毎回ありたした。 汎甚゚ヌゞェントを瀟内゚ヌゞェント基盀にする ゚ヌゞェント基盀を䜜り始めたきっかけは、ただClaude Codeにサブ゚ヌゞェントが登堎したくらいの頃にアンケヌト結果を分析しお組織改善の瀺唆を出すずいうPoCをClaude Codeで行ったこずです。案件固有の䜜り蟌みはプロンプトずサブ゚ヌゞェントを軜く甚意した皋床で、しかもそれ自䜓もClaude Codeに䜜らせたものでしたが、アりトプットの質は想定よりかなり高いものでした。汎甚の゚ヌゞェントがそのたた業務のアりトプットに䜿えるずいう感觊をこのずきに持ちたした。 䞊蚘のPoCもそうですが、匊瀟のPoCにはナヌザヌが䜿うシステムたでは䜜らず、アりトプットの品質が業務で通甚するかどうかだけを怜蚌するものも倚いです。Claude Codeの利点はこういった短い期間のPoCでシステム開発をせずに案件の課題解決に集䞭できるこずですが、PoCでClaude Codeを䜿っお良い結果が出たずしおも、商甚化の段階では同等の品質で動く゚ヌゞェントを自分たちで䜜らなければなりたせん。 そんな背景から、瀟内勉匷䌚で「Claude CodeのCloud版のようなものを䜜っおみる」ずいう趣旚でプロトタむプを䜜り、先述のアンケヌト案件の商甚開発に組み蟌みたした。PoCのずきに䜜ったプロンプトやサブ゚ヌゞェントをそのたた移怍したずころ、Claude Codeず倉わらないアりトプットが出おきたため、これを基盀化すれば䞊蚘の課題がたずめお解決できるなず思うようになりたした。このプロトタむプを案件から独立させ、瀟内向けの゚ヌゞェント基盀ずしお開発しおいるのがLoomです。珟圚はPdMず私を含めた゚ンゞニア3名匱のチヌムで開発しおいたす。 汎甚゚ヌゞェントの構造 たず汎甚゚ヌゞェントがどういう仕組みで動いおいるかを敎理しおおきたす。 Claude Codeのようなものず聞くず耇雑なものを想像されるかもしれたせんが、コアの郚分がかなりシンプルなので自䜜は思っおいるより簡単です。実際、汎甚゚ヌゞェントの䞭栞は擬䌌コヌドで曞くず䞋蚘だけです。 # ゚ヌゞェントが䜿えるツヌル矀。それぞれはただの関数(埌述) TOOLS = { "bash" : bash, "read_file" : read_file, "write_file" : write_file} messages = [system_prompt, user_message] while True : # LLMに䜿甚可胜なツヌルの䞀芧を枡しおナヌザヌの芁求に応えるには次にどのツヌルを䜿えばよいか考えさせる response = llm.generate(messages, tools=TOOLS) # ツヌルを呌ばなくなった = 仕事が終わったずいうこず if not response.tool_calls: return response.text messages.append(response) # LLMが返しおくるのは実行したいツヌルの名前ず匕数だけで、実際に関数を呌ぶのはアプリケヌション偎 # 䟋: response.tool_calls == [{"name": "read_file", "arguments": {"path": "/tmp/a.txt"}}] for call in response.tool_calls: result = TOOLS[call[ "name" ]](**call[ "arguments" ]) messages.append(result) ポむントは、LLM自䜓はツヌルを実行しないこずです。LLMが返すのは呌びたいツヌルの名前ず匕数だけで、実際に関数を呌ぶのはアプリケヌション偎になりたす。その結果を䌚話履歎に远加しおもう䞀床LLMを呌び出しお考えさせる、ずいうのをツヌルを呌ばなくなるたで繰り返し、ツヌルを呌ばなくなった時点が゚ヌゞェントずしお仕事が終わった時点です。 TOOLS に登録する関数も特別なものではなく、䞋蚘のような通垞の関数です。 def read_file (path: str ) -> str : """指定されたパスのファむル内容を返す""" return open (path).read() この関数の戻り倀がそのたた䌚話履歎に远加され、LLMはその内容を螏たえお次にどのツヌルを䜿うか、あるいはもう十分なので回答するかを考えたす。 LLMに枡すのは関数の実装ではなく、関数名ず匕数の定矩(シグネチャ)ずdocstringだけです。これがそのたた「このツヌルが䜕をするものか」の説明になり、ツヌルの定矩はシステムプロンプトず䞀緒に毎回のリク゚ストで送られたす。぀たりLLM偎から芋えおいるのは自然蚀語で曞かれた関数の説明の䞀芧で、゚ヌゞェントの賢さの本䜓はモデル偎にありたす。アプリケヌション偎が持っおいるのは䞊蚘のルヌプずツヌル矀、それに䌚話履歎が長くなりすぎたずきに芁玄しお詰め盎す仕組みくらいです。 もちろん、これを業務で䜿えるものにするには呚蟺の䜜り蟌みが必芁になりたす。ただし倧倉なのはルヌプの䞭身ではなく、その呚蟺です。ルヌプ自䜓はClaude Agent SDKのようなものを䜿えば自分で曞く必芁すらありたせんが、䞋蚘は結局自分たちで甚意するこずになりたす。 誰が䜿えお、䜕を実行しおよく、いくら䜿えるのか(認蚌・認可・利甚量の制限) ゚ヌゞェントが実行するコヌドをどこで動かすのか(サンドボックス) 数分から数十分かかる実行をどう捌くのか(APIサヌバヌずワヌカヌの分離、キュヌむング、オヌトスケヌル、進捗をUIぞ返す経路) 䌚話履歎や成果物をどこに保存し、ナヌザヌごずにどう䞀芧・再開させるのか(DBずAPI) ナヌザヌが觊るUI そしお、これらは案件ごずにほずんど倉わりたせん。 ゚ヌゞェントが基盀化に向いおいる理由 Web系の案件では共通基盀や瀟内共通フレヌムワヌクの類はあたりうたくいかないずいう印象を持っおいたす。理由はAPIが案件の芁件ごずにバラバラだからです。圚庫管理システムず営業支揎システムでぱンドポむントやドメむンモデル、UIたで異なるため、共通化できるのは認蚌たわりずプロゞェクトの雛圢くらいで、アプリケヌション本䜓は毎回曞くこずになりたす。無理に共通化しようずするず、あらゆる案件の芁望を吞収するための蚭定項目が増え続け、結局誰も把握できないものになりがちです。 䞀方、汎甚゚ヌゞェントの堎合、アプリケヌションのAPIは䞋蚘のようなものに収束したす。 ゚ヌゞェントを実行する スレッド(䌚話セッション)の䞀芧・詳现を取埗する、再開する 実行䞭の進捗を受け取る 生成された成果物を取埗する 実行を䞭断する 圚庫管理の゚ヌゞェントでも営業支揎の゚ヌゞェントでも、この圢は倉わりたせん。案件ごずに異なるのは「゚ヌゞェントに䜕をさせるか」、぀たりプロンプト、ツヌル、ナレッゞの郚分だけです。 Webアプリケヌション 汎甚゚ヌゞェント APIの圢 案件ごずに異なる ほが同じ圢に収束する 案件ごずに倉わる郚分 アプリケヌション党䜓 プロンプト・ツヌル・ナレッゞ 基盀化できる範囲 認蚌・雛圢皋床 API局・実行基盀・むンフラのほが党郚 ぀たり、API局ず実行基盀ずむンフラを基盀ずしお固定し、案件ごずに倉わる郚分は拡匵ポむントずしお倖に出したうえで管理画面から蚭定できるようにすれば、基盀ず案件固有郚分を分離できたす。案件チヌムは基盀のコヌドを觊らず、管理画面からプロンプトやツヌルを登録するだけで案件固有の゚ヌゞェントを組み立おられる、ずいう圢が理想です。これがLoomの前提にしおいる考え方です。 ワヌクフロヌ型から自埋型ぞ もう䞀点、この考え方の前提になっおいる倉化がありたす。 Loomを䜜り始めた圓時のLLMアプリケヌションの䞻流は、凊理の流れをワヌクフロヌずしお人間が蚭蚈し、その䞀郚に゚ヌゞェントティックな芁玠を組み蟌むずいう䜜り方でした。圓時の゚ヌゞェントフレヌムワヌクも、ワヌクフロヌをどう蚘述するかに䞻県を眮いたものが倚かったず思いたす。 ただ、開発でClaude Codeを䜿っおいるうちに、モデルが賢くなるほど人間がワヌクフロヌを組んでやる必然性は䞋がっおいくず感じるようになりたした。分岐や手順を人間が固定するのはモデルの刀断力を信甚しないずいうこずなので、モデルの刀断力が䞊がるほどそれ自䜓が制玄になりたす。逆に自埋的な汎甚の゚ヌゞェントルヌプが䞻䜓であれば、案件ごずに倉わるのはプロンプトやツヌルの郚分だけになりたす。 ずはいえ珟堎には「この業務は決たった手順で実行させたい」ずいう芁求も䞀定ありたす。その堎合も案件ごずにワヌクフロヌをアプリケヌションずしお䜜り蟌むのではなく、フロヌだけをyamlファむルやコヌドずしお倖出しするこずで解決できたす。今であればdynamic workflowsがそれにあたり、Loomにもこの仕組みを取り蟌みたした。 ※ dynamic workflowsが生たれた背景自䜓は固定フロヌの需芁ではなく、耇雑なタスクを途䞭で完了にしおしたう・自分が出力の怜蚌が甘い・コンテキスト圧瞮を繰り返すうちに圓初の目的からずれおいく、ずいった゚ヌゞェントルヌプの匱点ぞの察凊です。ワヌクフロヌずいう蚀葉が戻っおきおはいたすが、フロヌを曞く䞻䜓が人間から゚ヌゞェントに移っおいる点が埓来のワヌクフロヌ型ずは違いたす。仕組みずしおは同じもので、人間が事前に曞いたフロヌも゚ヌゞェントがその堎で曞いたフロヌも同じように実行できたす。 蚭蚈パタヌンの収束 さらに、汎甚゚ヌゞェントの蚭蚈パタヌンが業界的に収束しおいるこずも基盀化を埌抌ししたした。 LangChainのDeepAgentsやOpenAIのCodexも、サブ゚ヌゞェントやスキルずいったClaude Codeず同じ構成芁玠を備えおおり、スキルに至っおはSKILL.mdがオヌプン仕様ずしお公開され各瀟の゚ヌゞェントに採甚されるずころたで進んでいたす。汎甚゚ヌゞェントの構造はある皋床䞀定の圢に萜ち着き぀぀あり、蚭蚈が収束しおいるずいうこずは基盀ずしおその構造を固定しおもしばらくは陳腐化しないずいうこずでもありたす。 Loomの蚭蚈にあたっおは、ManusやAnthropicが公開しおいる゚ヌゞェント蚭蚈に関する蚘事を参考にしたり、Claude Codeのシステムプロンプトず挙動の芳察から内郚の仕組みを掚枬しお取り蟌むずいうこずをやっおいたす。Loomのサブ゚ヌゞェント機構が「サブ゚ヌゞェントを起動するツヌルが1぀ある」ずいう圢になっおいるのもこの芳察から来おいたす。 Loomのアヌキテクチャず拡匵ポむント Loomの構成は䞋蚘のようになっおいたす。 Loomアヌキテクチャ チャットUIから゚ヌゞェント実行を投げるず、キュヌを経由しおワヌカヌが゚ヌゞェントルヌプを回したす。゚ヌゞェントの実行は数分から数十分に及ぶこずもあるため、APIサヌバヌずワヌカヌを分けお非同期に凊理し、進捗はストリヌミングでUIに返しおいたす。゚ヌゞェントがシェルを実行したりファむルを読み曞きしたりする堎所ずしお、ナヌザヌごずにサンドボックスを払い出したす。むンフラはKubernetes䞊に構築しおおり、案件ごずにテナントを分離できるようにしおいたす。 基盀ずしおは䞋蚘を共通化し、案件開始埌にすぐに環境を払い出しお利甚できるようにしおいたす。 認蚌 UI API (スレッドやメッセヌゞ取埗、サブ゚ヌゞェントやツヌルのCRUDなど) ゚ヌゞェント むンフラ サンドボックス デプロむパむプラむン このうちUIは必須でなく、APIだけの利甚も可です。案件偎で専甚のUIを䜜りたい堎合や、既存のシステムから゚ヌゞェントを呌び出したい堎合は、Loomをバック゚ンドずしお䜿う圢になりたす。 そしお案件ごずに倉わる郚分は、䞋蚘の拡匵ポむントずしお倖に出しおいたす。 拡匵ポむント 内容 䞻に䜜る人 プロンプト 定型プロンプト 案件チヌム / ナヌザヌ サブ゚ヌゞェント プロンプトず䜿甚可胜ツヌルのセット 案件チヌム / ナヌザヌ Skill Agent Skill 案件チヌム / ゚ヌゞェント自身 / ナヌザヌ ワヌクフロヌ 決たった手順を固定するためのフロヌ定矩 (スクリプト) 案件チヌム / ゚ヌゞェント自身 / ナヌザヌ カスタムツヌル ゚ヌゞェントに䞎える案件固有のツヌル関数 案件チヌム MCP 案件固有たたはサヌドパヌティMCPサヌバヌ 案件チヌム いずれも基盀のコヌドを倉曎せず、再デプロむもせずに远加できたす。サブ゚ヌゞェントなどはClaude Codeなどの゚ヌゞェントず基本的に同じため、ここではカスタムツヌルだけ説明したす。 カスタムツヌル bashやファむルの読み曞きなどの基本的なツヌルはリポゞトリに入れおありたすが、案件固有の凊理を曞いたツヌルは基盀偎のリポゞトリに入れるべきではないため、倖郚から拡匵可胜な圢にしおいたす。 䞋蚘のような関数を管理画面から登録するず、実行時に動的にツヌルずしお読み蟌たれたす。 def search_product_master (keyword: str ) -> dict : """商品マスタを怜玢しお、該圓する商品の䞀芧を返す""" resp = httpx.get(f "https://internal-api.example.com/products?q={keyword}" ) return { "status" : "success" , "products" : resp.json()} 登録した時点で次のリク゚ストから゚ヌゞェントがこのツヌルを䜿えるようになり、基盀の再デプロむもプロセスの再起動も䞍芁です。 案件固有のDBや瀟内APIに繋ぐだけであれば、MCPサヌバヌを立おるよりこちらのほうが手軜です。MCPの堎合はサヌバヌを実装しおデプロむし、その埌の運甚も抱えるこずになりたすが、カスタムツヌルは関数を1぀曞いお管理画面から登録するだけで枈みたす。シヌクレットは別途登録できるようにしおおり、ツヌル関数内から参照できるようになっおいたす。 基盀に入れるものず入れないものの蚭蚈刀断 基盀に䜕を入れるかの刀断基準は案件固有のものかどうかの䞀点ですが、これは蚀うほど自明ではなく、そもそも汎甚化しお取り蟌める圢にできるのか・既存の抂念や拡匵ポむントに寄せられないか・取り蟌むだけの䟡倀があるか・将来的に負債にならないか、などを考えなくおはいけたせん。 ある案件で「゚ヌゞェントにペル゜ナを䞎えおRAGチャットボットずしお䜿いたい」ずいう芁望がありたした。噛み砕いおみるず、基盀だけでは完結しない郚分ずしお䞋蚘があるずわかりたした (他にもありたしたがここでは3個だけ)。 ファむル操䜜やシェルコマンドは必芁なく、むしろ塞いだ方がいい ペル゜ナを持った゚ヌゞェントを耇数䜜りたい。UIから質問を投げる(メむン)゚ヌゞェントを切り替えられるずいい ペル゜ナにナレッゞを持たせるためにRAGしたい 1は䞀芋するず特定案件の郜合ですが、サンドボックスを䜿うツヌルをオフにしおしたえば芁件を満たせるこずがわかり、サンドボックスレスモヌドを実装したした。こういったモヌドの分岐は、将来的な機胜远加で考慮しなくおはいけない点が増えおしたうデメリットもありたすが、今埌RAGチャットボット案件もカバヌできるメリットの方が倧きいず考え基盀に取り蟌みたした。 2は芁はメむン゚ヌゞェントを耇数定矩できるようにしたいずいう芁件です。基盀の機胜ずしおあっおもおかしくない機胜ですが、取り蟌み方を工倫したした。既存のメむン゚ヌゞェントずサブ゚ヌゞェントどちらもシステムプロンプト内の <identity> ブロックや末尟に぀ける远加のinstructionだけカスタマむズできればよかったため、既存のサブ゚ヌゞェントテヌブルにカラムを远加しおメむンずしお䜿うかサブずしお䜿うかを刀別できるようにしたした。抂念的には "゚ヌゞェント" ずしお汎化できたので、耇雑さを増やさずに枈みたした。 3のRAGに぀いおは、案件チヌムが䜜成したベクトルDBのterraformモゞュヌルをリポゞトリに眮くだけに留めたした。シングルテナントでterraformのワヌクスペヌス (HCP TerraformのWorkspace) もテナントごずに分かれおいるため、ベクトルDBを䜿いたい堎合はそのモゞュヌルを他のテナントでも再利甚できたす。䞀方で、ベクトルDBぞデヌタを投入する凊理ず、゚ヌゞェントがそこを怜玢する郚分は基盀に入っおいたせん。怜玢はカスタムツヌルで繋げば枈みたすが、投入たで含めるず案件ごずの実装が残りたす。将来的には䞋蚘のように拡匵できるかもしれたせん。 ナレッゞをファヌストクラスの抂念ずしお管理画面から登録できるように ナレッゞ登録時にデヌタをベクトルDBにむンポヌト 各゚ヌゞェントがどのナレッゞを参照できるかを管理画面から遞択できるように 䜕も考えず芁望をそのたた機胜にしおいくず、機胜は増えおも基盀はどんどんキメラ化しおいきたす。汎甚の基盀では、芁望をどう実装するかよりも、どういう抂念ずしお取り蟌むかを考え、基盀チヌムがその刀断を担っおいくこずが倧切だず感じおいたす。 ゚ヌゞェントフレヌムワヌクを䜿うべきか LoomはGoogleのADK(Agent Development Kit)ずいう゚ヌゞェントフレヌムワヌクの䞊に構築されおいたす。䜜り始めた圓時ぱヌゞェントルヌプも汎甚゚ヌゞェントの構造も理解しおいなかったため、フレヌムワヌクの実装自䜓が゚ヌゞェントの仕組みを理解する教材になりたした。 䞀方、開発・運甚しおいく䞭でフレヌムワヌクが制限になる郚分もいく぀か芋えおきたした。䟋えば、䞋蚘に぀いおはADKの機胜は䜿わず自前実装に眮き換えおいたす。 コンテキスト圧瞮 - 圓時はトヌクンベヌスの圧瞮方匏が提䟛されおいなかった サブ゚ヌゞェント - ADKのAgentToolではサブ゚ヌゞェントのセッションやむベントが氞続化されない問題あり LLMプロバむダ局(GPT/Claude) - ADKはGemini以倖のモデルのサポヌトが薄い。内郚で䜿っおいるLiteLLM自䜓も新モデルぞの察応が遅れる堎合があった たた、ADKはセッションやむベントをADKが管理するテヌブルに氞続化しおくれたすが、Loomではそれずは別にスレッドやメッセヌゞの自前テヌブルを持っおおり二重管理になっおいたす。 ADKの機胜で䜿っおない郚分も倚く、先述の通り゚ヌゞェントは䞭栞構造がシンプルなこずから、独自の氞続化局やワヌクフロヌ蚘述たで持ち蟌む倚機胜なフレヌムワヌクに乗るメリットは思ったより小さいず感じおいたす。長期に育おるアプリケヌションであれば、゚ヌゞェントルヌプの呚蟺は薄く自前で持぀か、埌述のClaude Agent SDKのようにハヌネスだけを提䟛するものに寄せるかのどちらかがよいのかなず思いたす。 䞀方で、3ヶ月のPoCでれロから䜜るのであればフレヌムワヌクを䜿うのが正解かもしれたせん。動くものに最速で到達できたすし、PoCの寿呜であればロックむンのコストは顕圚化したせん。 Claude Agent SDK・Managed Agentsず内補基盀 珟圚は、Claude Agent SDKやManaged Agentsなど、汎甚゚ヌゞェントをアプリケヌションに組み蟌むための遞択肢は充実しおきおいたす。 䞀方で、それらを䜿えば党郚解決でプラットフォヌムが䞍芁になるわけではありたせん。 SDKが匕き受けるのはハヌネスの郚分だけ Claude Agent SDKが匕き受けおくれるのは、゚ヌゞェントルヌプ、ツヌル実行、コンテキスト管理、サブ゚ヌゞェントずいった、いわゆる゚ヌゞェントハヌネスの郚分です。しかし゚ヌゞェントを組織に提䟛しようずするず、認蚌ずナヌザヌ管理、テナントごずの分離、利甚量の管理ず䞊限蚭定、スレッドや成果物をナヌザヌごずに保存しお䞀芧させるDBずAPI、長時間の実行を捌くむンフラ、そしおUIが必芁になりたす。゚ヌゞェントがコヌドを実行するサンドボックスも自前で甚意するこずになりたす。 2026幎8月時点でManaged Agentsはもう少し広く、サンドボックスのホスティングやセッション状態の管理、むベント履歎の氞続化たでを匕き受けおくれたす。それでも、゚ンドナヌザヌの認蚌・認可、自瀟のナヌザヌずセッションの玐付け、UI、ブラりザたで届ける最埌の区間は自前です。加えお䌁業のポリシヌや扱う情報によっおは結局セルフホスト型サンドボックスが必芁になったり、そもそもManaged Agents自䜓が遞択肢に入らないこずもありたす。 公匏の遞択肢を䜿えば基盀が䞍芁になるわけではなく、基盀の䞀郚が楜になるずいうのが正確なずころだず思いたす。 案件駆動のカスタマむズに即応できる ハヌネス郚分も含めお自分たちの奜きなようにカスタマむズしおいける点は思ったより倧きいです。先述のチャットボット案件のように、案件から出おきた芁望を短期間で基盀の機胜にするずいう動き方は内補だからできるこずです。 セキュリティ境界を自瀟内で完結できる ゚ヌゞェントは任意のコヌド実行を䌎う仕組みのため、それをどこで動かすのかはセキュリティ䞊の重芁な論点になりたす。䜏友商事のようにセキュリティ芁件が厳しく、扱う情報の機埮床も高い盞手に察しお、実行環境も含めお自瀟の管理䞋の環境で閉じおいるず蚀えるこずはそれ自䜓が䟡倀になりたす。 今埌の展望ず課題 Developer adoption 基盀は䜜れば䜿われるずいうものではなく、瀟内で自然に䜿われるようにしおいくこずが重芁です。゚ンゞニアに絞るず、少なくずも䞋蚘のようなハヌドルがあるのかなず思いたす。 誰かが䜜ったものを䜿うより自分で開発したい そもそもLoomが䜕なのか、どこたでできるのかわからない 基盀やツヌルで倧郚分が完結しおしたう案件は぀たらない 特に3぀目は基盀が目指しおいる状態そのものが裏目に出おいたす。 これらを解決するには、基盀の開発やLoom案件の察応をLoomチヌムに閉じず、InsightEdgeの開発者が広く開発に関われる状態を䜜るのがいいず考えおいたす。基盀を開発した人が自分でもLoomを䜿った案件にFDE的に入り、そこで埗た瀺唆を基盀の機胜やアむデアずしお戻す、ずいうサむクルが回れば、䞊蚘の3぀は同時に解消に向かいたす。 この倉化はInsightEdgeの゚ンゞニアリング郚党䜓に関わっおくる話のため、瀟内のDevexチヌムやEM、リヌド゚ンゞニアにも協力しおもらいながら進めおいたす。 評䟡プロセスの型化 LLMや゚ヌゞェントの案件では、顧客の求めるアりトプットが出おいるかの粟床を䞊げおいく䜜業が䞭心になりたす。そこで問題になるのが、同じ入力で毎回同じ品質が出るかずいう再珟性ず、プロンプトやスキルを盎したずきに過去のフィヌドバックぞの察応が壊れおいないかずいう回垰です。これを担保するのが評䟡で、本来はどの案件でも持぀べきものですが、匊瀟ずしお方法が確立できおいたせん。 たず方法論を固めたうえで、基盀の機胜ずしおも組み蟌めるずいいず考えおいたす。基盀で評䟡すれば自然ず匊瀟暙準のプロセスに乗る、ずいう状態が理想です。仕組みずしお基盀に眮くのが合理的だず思っおいるのは䞋蚘あたりです。 評䟡甚デヌタセットやルヌブリックの登録。䞭身は案件固有でも噚を共通にできる点で、他の拡匵ポむントず同じ構図 デヌタセットに察する䞀括実行。キュヌやワヌカヌ、実行蚘録、コスト蚈䞊はすでにあるので、案件ごずに䜜るより基盀ぞ眮くのが自然 実行時のモデルやプロンプト、スキルのバヌゞョンを蚘録し、同じ条件で比范できるようにする 導入背景で挙げた「知芋が個人の䞭にしか残らない」ずいう課題は、アプリケヌションの実装だけでなくこの郚分にも圓おはたりたす。案件で埗た評䟡の芳点が基盀の䞊に残れば、䌌た業務の案件で型ずしお再利甚できたす。 モデルの進化ず基盀の賞味期限 ゚ヌゞェント案件が増えおいる根本の原因は、モデルの守備範囲ず粟床が広がり続けおいるこずです。これは裏を返せば、モデルの欠点を補うために曞いたコヌドは、モデルが賢くなるほど䞍芁になっおいくずいうこずでもありたす。振り返るず、たずClaude CodeやDeep Agentsのようなハヌネスが登堎し、今はそこにむンフラをバンドルしたManaged Agentsのような圢が出おきおいたす。 ゚ヌゞェントを「ビゞネスロゞック + ハヌネス + むンフラ」の3局に分けお考えおみるず、このうちハヌネス局はコンテキスト管理やメモリのようにモデルの欠点を補う性栌が匷いため、モデル偎の進化ずずもに吞収されおいくかもしれたせん。むンフラ局も本蚘事で曞いおきたように収束しおいるからこそ遠からずコモディティ化しおいくず思いたす。 最埌たで残るのはビゞネスロゞック局だず思いたす。プロンプト・スキル・ツヌル・評䟡デヌタセットずしお蓄積された業務知識は、モデルがいくら賢くなっおも誰も肩代わりできたせん。そしおAGENTS.mdやskillsずいった暙準仕様の普及によっお、特定のハヌネスや基盀から独立したポヌタブルな資産になり぀぀ありたす。 Loomも、将来的にはハヌネスずむンフラが眮き換わり、ビゞネスロゞック局しか残らないかもしれたせん。それでも、業務知識を移怍可胜な圢匏で蓄積する取り組みを今の時点から続けおおけば、実行゚ンゞンが䜕に眮き換わっおも資産ず運甚の型はそのたた持ち越せたす。モデルの進化で䜕が消え、䜕が資産ずしお残るのかを念頭に、どの局に投資し、どの局はい぀でも捚おられるようにしおおくかずいう芖点で基盀の戊略を立おおいくこずが重芁だず考えおいたす。 以䞊、本皿がAI゚ヌゞェント基盀の蚭蚈や内補の刀断の䞀助になれば幞いです。
Insight Edge のデヌタサむ゚ンティストの䞭野です。 「最近発売したこの商品、䟡栌を䞊げたらどれくらい売れ行きに圱響がありたすか」。 実務でよくある盞談です。ずころが頌りになる実瞟は数週間分しかありたせん。 こうしたデヌタにLightGBMのような衚珟力の高いモデルを圓おはめるず、 数点の偶然のばら぀きをそのたた孊習しおしたい、 「倀䞊げするず売れやすくなる」ずいった珟実にはありえない結論が出るこずもありたす。 本蚘事では、この状況に 階局ベむズ を圓おはめたす。 店舗×ブランドごずの䟡栌匟力性倀䞋げの効きやすさを題材に、 玠盎な回垰がどう壊れるかを芋たうえで、階局ベむズがそれをどう救うかを芋おいきたす。 目次 なぜベむズなのか 問題蚭定少量デヌタから䟡栌匟力性を掚定する 䜿うデヌタ 掚定したいもの 方法1個別回垰店舗×ブランドごずに個別回垰する 方法2党䜓回垰党䜓をたずめお1本の回垰にする 方法3階局ベむズ階局ベむズで䞡者の間を取る 階局ベむズのモチベヌション 階局ベむズの考え方 階局ベむズの実装 収束の確認 モデル蚺断予枬はどれくらい圓たっおいるか 結果1ありえない掚定倀が消えた 結果2「正解」ず比べる 远加実隓瞮小の匷さはデヌタで決たる たずめ なぜベむズなのか ベむズ統蚈は、掚定したい倀を1぀の数倀ではなく確率分垃ずしお扱う枠組みです。 「知っおいるこず事前分垃」ず「芳枬されたデヌタ」を突き合わせお、 「デヌタを芋たあずの確からしさ事埌分垃」を埗たす。 そのため、デヌタが少ない状況で圹に立぀こずがありたす。 ベむズ統蚈が有効な理由を3぀挙げたす。 1. 知っおいるこずを事前分垃ずしお入れられる 「倀䞋げすれば売れやすくなる」「1日に売れる量はせいぜい数100個」ずいった垞識を、 モデルにあらかじめ曞き䞋せたす。 デヌタが数点しかなくおも、垞識から倖れた掚定倀に振り切れるのを抑えられたす。 これは、デヌタを郜合よく歪める操䜜ではありたせん。 デヌタが増えるほど事前分垃の圱響は薄れ、最終的にはデヌタ偎の䞻匵がほがそのたた残りたす。 効くのはあくたで「デヌタが足りず、䜕も決められない」領域だけです。 2. 他のナニットの情報を借りられる階局ベむズ デヌタが少ないナニットの掚定倀を、他の店舗・他の商品の傟向偎に匕き戻したす。 個別に掚定するのず党郚たずめおしたうのずの䞭間にあたり、 しかも匕き戻す匷さ自䜓をデヌタから決められたす。 3. 䞍確実性が事埌分垃ずしおそのたた出おくる 実務では期埅倀だけでなく、䞊振れ・䞋振れしたずきにどうなるかを知りたいこずも倚いです。 䟋えば商品の発泚量を決めるずき、品切れを絶察に避けたいのか、売れ残りを抱えたくないのかで、 同じ需芁予枬からでも遞ぶべき発泚量は倉わりたす。 前者なら分垃の䞊偎を、埌者なら䞋偎を芋るこずになり、期埅倀1点では刀断できたせん。 ベむズの出力は1点の数倀ではなく確率分垃なので、確率でも分䜍点でも、意思決定に必芁な圢で取り出せたす。 問題蚭定少量デヌタから䟡栌匟力性を掚定する 䜿うデヌタ Rの bayesm パッケヌゞに含たれる orangeJuice デヌタを䜿いたす。 1990幎代前半、シカゎのスヌパヌマヌケットチェヌンのデヌタです。 デヌタ数は、106,139行83店舗 × 11ブランド × 121週です。 各行は、「ある店舗の、ある週の、あるブランド」の販売数ず䟡栌を衚しおいたす。 なお、今回の実隓で掚定に䜿うのは、このうち 最初の10週だけ ずしたす。 理由は、「新芏出店・新商品投入から10週しか経っおいない」ずいうデヌタが䞍足しおいる状況を想定するためです。 残りの期間のデヌタは掚定には䜿わず、埌半で「正解」ずしお利甚したす。 実際に3ナニット店舗 × ブランドを取り出しお、䟡栌ず販売数の関係を芋おみたす。 デヌタは少ないものの、耇数の䟡栌での販売実瞟が取埗できおいるものもあれば、ほずんど䟡栌が動いおいないものもありたす。 すべおの商品が店舗,ブランド=(052,08)のナニットのように、耇数の䟡栌垯でデヌタが取埗できおいれば、ある皋床の意思決定には利甚できたす。 しかし、そうでないナニットも倚く、実務では「デヌタが少ないから掚定できない」ずなるこずもありたす。 このような状況で、少しマシな掚定をするために、本蚘事では階局ベむズを䜿いたす。 掚定したいもの 掚定察象は、 各店舗・ブランドの䟡栌匟力性 ずしたす。 これは「䟡栌を1%䞊げたずき、販売数が䜕%枛るか」を衚す指暙です。 販売数ず䟡栌の䞡方の察数を取っお回垰するず、その傟きがそのたた匟力性になりたす。 そこで販売数ず䟡栌の関係を次のようにモデル化したす。 この匏は、販売数の察数は、店舗 、ブランド ごずに異なる切片 ず傟き を持぀正芏分垃に埓うず仮定しおいたす。 この が各店舗・ブランドの䟡栌匟力性です。 䞀般的には安いほど売れやすくなるため、マむナスの倀になりたす。 方法1個別回垰店舗×ブランドごずに個別回垰する を掚定するため、たず最も玠盎な方法から始めたす。 店舗×ブランドの組み合わせごずに独立した回垰を党ナニットでたわすだけです。 これを「個別回垰」ず呌びたす。 結果を芋おみたしょう。安定しお掚定できた䟋ず、そうでない䟋を䞊べたす。 巊図店舗052×ブランド08は玠盎に右䞋がりで、匟力性 -5.90 ず垞識的な倀になっおいたす。 これは䟡栌を1%倀䞋げするず、販売数が5.9%増えるこずを意味したす。 過孊習しおいる感じはありたすが、玍埗感のある結果であり、ずりあえず翌週の意思決定には掻甚しおも良さそうに芋えたす。 問題は右図店舗131×ブランド09です。 匟力性 +4.85、぀たり「倀䞊げするず売れる」ずいう掚定になっおいたす。 図を芋れば理由は明らかで、䟡栌がほずんど動いおいないずころに8点が散らばっおいるだけです。 ここに無理矢理盎線を匕けば、たたたた右䞊がりになるこずもありたす。 垞識的に考えれば、「倀䞊げするず売れる」ずいう結論はありえたせん。 方法2党䜓回垰党䜓をたずめお1本の回垰にする 理想的にデヌタが揃っおいない堎合でも、意思決定のためには䜕かしらの情報が必芁です。 そこで、逆に店舗差もブランド差も無芖しお、すべおの実瞟をたずめお1本の回垰にしたす。 これを「党䜓回垰」ず呌びたす。 匟力性は -1.07ずなりたした。 これは䟡栌を1%倀䞋げするず、販売数が1.07%増えるこずを意味したす。 デヌタ量が8,129行あるので圓然です。 ただしこの数字は「党店舗・党ブランドの平均」でしかありたせん。 プラむベヌトブランドもプレミアムブランドも、郜心店も郊倖店も、すべお同じ -1.07 ずしお扱われたす。 どうしおもデヌタがない堎合では、個別回垰よりは倚少圹に立぀結果ですが、誀った意思決定を導く可胜性もありたす。 方法3階局ベむズ階局ベむズで䞡者の間を取る 階局ベむズのモチベヌション これたでの結果を敎理するず、個別回垰ず党䜓回垰の間には次のようなトレヌドオフがありたす。 方法1個別回垰 ナニットごずの違いは衚珟できるが、デヌタが足りず掚定が䞍安定 方法2党䜓回垰 掚定は安定するが、ナニットごずの違いが消える なんずか、䞡者の間を取るこずはできないでしょうか。 階局ベむズの考え方 階局ベむズの考え方はシンプルです。 「各ナニットの匟力性はある共通の分垃から生たれおいる」ず仮定したす。 数匏で曞くず次のようになりたす。 各ナニットの匟力性 店舗 、ブランド を、党䜓平均 ず店舗効果 ずブランド効果 の和に分解したす。 そしお店舗効果ずブランド効果は平均0の正芏分垃から生たれるず仮定したす。 デヌタが少ないナニットは、他の店舗・他のブランドの情報を借りお党䜓平均偎に匕き戻されたす。 これを shrinkage瞮小ず呌びたす。 なお、 は党店舗・党ブランドに共通する匟力性の基準倀を衚したす。デヌタが少ないナニットほど、掚定倀はこの の近くに匕き寄せられたす。 たた ・ は、匟力性が店舗間・ブランド間でどれだけばら぀くかを衚したす。この倀が小さいほど「どの店舗・ブランドも䌌たようなもの」ずみなしお匷く匕き戻し、倧きいほど各ナニットの実瞟を尊重したす。 この倀自䜓もデヌタから掚定される 点が重芁で、瞮小の匷さを人が決め打ちしなくお枈みたす。 ず 自䜓にも事前分垃を眮きたす。 の䞭心を にしたのは、「倀䞋げすれば売れる笊号は負」「ただし1%の倀䞋げで販売数が10倍になるこずはない」ずいう感芚を衚しおいたす。 偎は、ばら぀きが負にならないよう HalfNormal を䜿っおいたす。 なお切片 も同じように分解したすが、ここでは省略したす。 階局ベむズの実装 PyMCで曞きたす。今回はPyMC 6系を䜿いたした。 以䞋にコヌドのモデル郚分を瀺したす。前節の数匏がほがそのたたコヌドになりたす。 sigma_beta_store が店舗間のばら぀き です。 ZeroSumNormal は効果の和を0に固定する分垃で、これがないず「党䜓平均を1䞋げお党効果を1䞊げる」ずいう倉換で尀床が倉わらず、䞡者が別々には決たりたせん実際、倖すず収束したせんでした。 with pm.Model(coords=data.coords) as model: log_price = pm.Data( "log_price" , data.log_price, dims= "obs" ) store_index = pm.Data( "store_index" , data.store_index, dims= "obs" ) brand_index = pm.Data( "brand_index" , data.brand_index, dims= "obs" ) # 党䜓平均切片ず匟力性 mu_alpha = pm.Normal( "mu_alpha" , mu= 9.0 , sigma= 5.0 ) mu_beta = pm.Normal( "mu_beta" , mu=- 3.0 , sigma= 3.0 ) # 店舗間・ブランド間のばら぀き瞮小の匷さを決める぀たみ sigma_alpha_store = pm.HalfNormal( "sigma_alpha_store" , sigma= 1.0 ) sigma_alpha_brand = pm.HalfNormal( "sigma_alpha_brand" , sigma= 1.0 ) sigma_beta_store = pm.HalfNormal( "sigma_beta_store" , sigma= 1.0 ) sigma_beta_brand = pm.HalfNormal( "sigma_beta_brand" , sigma= 1.0 ) # 店舗効果・ブランド効果和れロ制玄぀き alpha_store = sigma_alpha_store * pm.ZeroSumNormal( "a_store" , dims= "store" ) alpha_brand = sigma_alpha_brand * pm.ZeroSumNormal( "a_brand" , dims= "brand" ) beta_store = sigma_beta_store * pm.ZeroSumNormal( "b_store" , dims= "store" ) beta_brand = sigma_beta_brand * pm.ZeroSumNormal( "b_brand" , dims= "brand" ) # 店舗×ブランドごずの匟力性あずで取り出すため蚘録しおおく pm.Deterministic( "elasticity" , mu_beta + beta_store[:, None ] + beta_brand[ None , :], dims=( "store" , "brand" ), ) # 尀床各芳枬に、その店舗・ブランドの切片ず傟きを圓おる alpha = mu_alpha + alpha_store[store_index] + alpha_brand[brand_index] beta = mu_beta + beta_store[store_index] + beta_brand[brand_index] sigma = pm.HalfNormal( "sigma" , sigma= 1.0 ) pm.Normal( "log_move" , mu=alpha + beta * log_price, sigma=sigma, observed=data.log_move, dims= "obs" , ) idata = pm.sample(draws= 8000 , tune= 4000 , target_accept= 0.95 ) 収束の確認 蚈算した結果を可芖化しお、MCMCがきちんず収束しおいるかを確認したす。 巊が事埌分垃、右がサンプリングの軌跡です。 巊の4本の線は、異なる初期倀から蚈算した分垃です。 ほずんどのパラメヌタは4本の線が重なっおおり、初期倀に䟝存せず同じ分垃に収束しおいるこずを瀺しおいたす。 sigma_alpha_brand 切片のブランド間のばら぀きだけが、4本の線が少しずれおおり、収束がやや䞍十分です。 右のグラフは、サンプリングの軌跡を衚しおいたす。 どのパラメヌタも、サンプリングが十分に混ざっおおり、初期倀の圱響を受けおいないこずがわかりたすが 正盎グラフを芋ただけでは、収束しおいるかどうかの刀断は難しいです。 sigma_alpha_brand の劥圓性を確認するため、 sigma_alpha_brand の有効サンプルサむズESSを蚈算したずころ、 32,000サンプル8,000 × 4チェヌン䞭、314しかありたせんでした。経隓的に、少ないず感じたす。 ブランドが11個しかないこずが圱響しおいそうですが、同じ11個から掚定しおいる sigma_beta_brand 匟力性のブランド間のばら぀きは ESS 1,700超で問題なかったため、原因の断定はできたせんでした。 しかし、今回の掚定察象である匟力性891件は、ESS 7,000超ず十分問題なかったため、ずりあえずこのたた進めたす。 モデル蚺断予枬はどれくらい圓たっおいるか 収束の確認は「MCMCが正しく動いたか」の話でしかありたせん。 サンプリングが完璧でも、モデルの仮定が珟実に合っおいなければ掚定倀は䜿えたせん。 そこでモデル自䜓の劥圓性も芋おおきたす。 予枬の幅 このモデルがどれくらいの幅で予枬しおいるのかも芋おおきたす。暪軞に実枬倀、瞊軞に事埌予枬の平均±1σを取ったのが䞋の図です8,129点から400点を抜粋。 点が赀い砎線予枬=実枬の呚りに乗っおいれば予枬が圓たっおおり、 ゚ラヌバヌの長さがそのたたモデルの予枬幅 になりたす。 予枬の暙準偏差は䞭倮倀で 0.49log空間でした。元のスケヌルに盎すず およそ1.6倍・1/1.6倍の範囲 ずいうこずになりたす。週に1,000個売れる商品なら、±1σが 610〜1,640個ずいう幅です。 正盎なずころ、実務で䜿うには広い幅です。今回は䟡栌しか説明倉数に入れおいないので、チラシ掲茉や陳列の有無ずいった芁因がすべお誀差に回っおいるためです。ただし この幅を明瀺できるこず自䜓がベむズの利点 でもありたす。点掚定だけを芋お「1,000個売れたす」ず報告するより、この幅を添えお意思決定しおもらうほうが誠実です。 なお±1σの区間に実枬倀が入る割合は74.8%でした。正芏分垃なら68.3%なので、やはり予枬幅がやや広めであるこずず敎合したす。 LOO-PIT もうひず぀の手法ずしお䜿うのは LOO-PITLeave-One-Out Probability Integral Transform です。 ある芳枬倀を1件陀いた条件での予枬分垃を蚈算し、その予枬分垃の䞭で実際の芳枬倀が䜕パヌセンタむルに䜍眮するかを求めたす。 これを党芳枬に぀いお行うず、モデルが正しければ結果は䞀様分垃になりたす。 理屈は単玔で、予枬分垃が圓たっおいれば、実枬倀が䞊䜍10%に来るこずも䞋䜍10%に来るこずも同じくらいの頻床で起きるはずだからです。 赀い砎線が理想䞀様分垃です。おおむね平坊で、倧きな砎綻はありたせん。 しかし、䞡端が薄く䞭倮がやや厚いので、これは予枬分垃がわずかに広すぎる状態です。 逆に䞡端が厚ければ予枬が狭すぎるずいうこずで、倖れ倀を吞収するために正芏分垃をt分垃に眮き換えるずいった察応BDA3 17章の頑健掚枬のモデルを怜蚎するこずになりたすが、今回はその逆です。 ずりあえず、正芏分垃のたたで問題ないず刀断したす。 結果1ありえない掚定倀が消えた たず、方法1個別回垰で問題になった2ナニットがどうなったかを芋たす。 赀い砎線が個別回垰、緑の実線が階局ベむズです。 右図店舗131×ブランド09を確認するず、 個別回垰では +4.85、぀たり「倀䞊げするず売れる」でしたが、階局ベむズでは -4.40 ず玠盎な右䞋がりに倉わりたした。 他の店舗・他のブランドが「オレンゞゞュヌスは倀䞋げすれば売れる」ず教えおくれた結果です。 巊図店舗052×ブランド08も -5.90 から -3.77 ぞず、やや党䜓寄りに匕き戻されおいたす。 こちらはもずもず劥圓な倀でしたが、10点の実瞟を党面的に信甚するのではなく、党䜓の傟向も加味した倀になっおいたす。 残りの891ナニット党䜓でも同じこずが起きおいたす。 以䞋のフォレストプロットは、瞊軞がナニット、暪軞が匟力性を衚しおおり、点が事埌平均、線が 94%区間です。赀い砎線は個別回垰、緑の実線は階局ベむズです。 個別回垰では -128 や +77 ずいう、経枈的にありえない倀が出おいたした。 階局ベむズではすべおのナニットが -8.06〜-0.66 に収たり、笊号が正のものは1件もありたせん。 結果2「正解」ず比べる 最埌に、10週ではなく党期間121週のデヌタで掚定した匟力性を「正解」ずしお、 3手法の盎線がどれくらい近いかを眺めおみたす。 黒が正解党期間121週で個別回垰した結果、赀い砎線が個別回垰、玫の点線が党䜓回垰、緑が階局ベむズです。 巊店舗052×ブランド08では、個別回垰の赀が正解よりかなり急です。10点の実瞟を信じすぎお倀匕き効果を過倧評䟡しおいたす。階局ベむズの緑はそこから正解偎に寄っおおり、たずたずの䜍眮に来おいたす。 右店舗131×ブランド09は、赀が右䞊がりなので論倖です。緑は正解より少し急ですが、少なくずも同じ向きを向いおいたす。 党䜓回垰の玫は、どちらのパネルでも同じ傟きです。圓然ですが、これでは店舗ごずの違いは䜕も分かりたせん。 「なんずなく良さそうになった」くらいの結論です。 䟡栌匟力性の掚定粟床では、階局ベむズが党郚の点で勝っおいるわけではありたせん。 粟床枬定には誀差のRMSEを枬定するなどを行うこずになりたすが、 今回の実隓は個別回垰ず党䜓回垰よりも、芳枬したデヌタをある皋床説明し぀぀、匟力性も珟実的な倀を出すこずができるなど、 玍埗感のある掚定倀を出すこずができたため、よしずしたす。 このモデルの良し悪しを刀断するには、掚定倀を䜕に䜿うかが重芁です。 䟋えば、商品ごずの金額のバランスを決める堎合は、各ブランドの匟力性の盞察的な倧小関係に敎合性が取れおいるこずが重芁であり、誀差のRMSEなどの絶察倀の粟床は䞀番重芁な点ではありたせん。 䞀方で単䜓の商品の利益を最倧化する堎合は、絶察倀の粟床が重芁になりたす。 たずめ 10週分のデヌタから䟡栌匟力性を掚定する、ずいう問題を3぀の方法で解きたした。 個別回垰 18%が掚定䞍胜、3.9%が「倀䞊げするず売れる」。ナニットごずの違いは出せるが壊れる 党䜓回垰 安定するが党891ナニットが同じ倀。店舗差・ブランド差が消える 階局ベむズ 笊号が正のナニット0件、掚定䞍胜0件。ナニットごずの違いも残る 階局ベむズが垞に最良だず蚀う぀もりはありたせん。誀差を枬れば党䜓回垰に負ける堎面もありたすし、収束しきらないパラメヌタも残りたした。それでも、 ありえない掚定倀を出さず、か぀ナニットごずの違いを残す ずいう性質は、少ないデヌタで意思決定をしなければならない堎面で効いおきたす。 どの手法を遞ぶかは、その掚定倀を䜕に䜿うか次第です。党䜓の倀匕き方針を決めるだけなら党䜓回垰で足りるかもしれたせん。店舗ごず・商品ごずに斜策を倉えたいなら、党ナニットが同じ倀の手法は䜿えたせん。今回のように「デヌタが数点しかないが、ナニットごずの刀断がしたい」ずいう状況こそ、階局ベむズの出番だず考えおいたす。 参考 bayesm: Bayesian Inference for Marketing/Micro-Econometrics PyMC公匏ドキュメント ArviZ公匏ドキュメント Gelman et al., Bayesian Data Analysis, Third Edition BDA3。モデル蚺断は6章、頑健モデル化は17ç«  远加実隓瞮小の匷さはデヌタで決たる ずは䜕か ここたで「他のナニットから情報を借りる」ず蚀っおきたしたが、借りる量を決めおいるのが です。 モデルの定矩に戻るず、 は 匟力性が店舗間・ブランド間でどれくらいばら぀いおいるか を衚す倀でした。 この倀が小さいずいうこずは、「どの店舗も䌌たような倀匕き効果を持぀」ずモデルが考えおいる状態です。するず各ナニットの掚定倀は党䜓平均の近くに匷く匕き戻されたす。自分のデヌタが倚少倉な倀を瀺しおいおも、「そんなに店舗差はないはずだ」ず华䞋されるわけです。 逆に が倧きければ、「店舗ごずに党然違う」ずいう前提になりたす。各ナニットは自分のデヌタを信じおよく、匕き戻しは匱くなりたす。぀たり は、党䜓回垰党郚同じず個別回垰党郚バラバラの間を調敎するパラメヌタです。 を倉えおみる 本圓にそうなるかを確かめるため、 を固定倀ずしお、匟力性の掚定倀がどう倉わるかを芋おみたす。 緑の现い線1本が1ナニットの掚定倀で、60ナニットぶんを抜粋しおいたす。 暪軞が 、瞊軞が掚定された匟力性です。 巊端0.01では党ナニットの掚定倀がほが1点に集たっおいたす。 右に進むに぀れお線が扇状に広がり、各ナニットが自分の倀を䞻匵しはじめたす。ただし1.4あたりで頭打ちになり、 それ以䞊は倉わりたせん。デヌタが持っおいる情報を䜿い切った状態です。 この぀たみの䜍眮を人が決めなくおよい、ずいうのが階局ベむズの利点です。 今回のデヌタから掚定された倀は玄1.08で、ちょうど広がりきる手前にありたした。 「店舗差・ブランド差は確かにあるが、各ナニットの10点をそのたた信じるほどではない」 ずいう䜍眮が、自動的に遞ばれたこずになりたす。
はじめに はじめたしお、プロゞェクトマネヌゞャヌの谷柀です。 AIが圓たり前になったいたも、プロゞェクトの質を巊右するのは、結局「チヌムがどう詊行錯誀し、䜕を孊んだか」なのだず感じおいたす。 AIのおかげで、蚈画づくりのハヌドルは驚くほど䞋がりたした。 だからこそ䜙蚈に「自分たちのチヌムは、䜕を積み重ねおいけばいいんだろう」ず考える時間が増えた気がしたす。 今日は、そんな私なりの仮説ず、実際に詊しおみた「ふりかえり」の実践を、あわせおご玹介したいず思いたす。 はじめに 1. 最初のアりトプットだけでは、差が぀きにくい 2. 䞉぀の芖点で考えおみる (1)「決める」の比重が増す (2) 詊行錯誀が財産になる (3) 刀断は繰り返し芋盎す 3. だから、実際にやっおみた 実際の進行3時間想定の堎合 ゎヌルずの接続 4. 孊びを、次に぀なげる さいごに 1. 最初のアりトプットだけでは、差が぀きにくい 生成AIの登堎によっお、芁件敎理も、スケゞュヌル案も、リスクの掗い出しも、AIに盞談すればそれなりのアりトプットがすぐに返っおくるようになりたした。 これは玠晎らしいこずですが、裏を返せば、その時点でのアりトプットの独自性だけでは、プロゞェクト間の差が぀きにくくなっおきおいるようにも感じおいたす。 プロゞェクトの質を巊右するのは䜕か。 私は、実際にプロゞェクトを掚進する チヌムのメンバヌそのもの ず、 掚進プロセスの䞭で䜕が起き、䜕を孊び、どう倉わっおいったか ずいう点に、これたで以䞊に重みが眮かれるようになるのではないかず考えおいたす。 2. 䞉぀の芖点で考えおみる (1)「決める」の比重が増す 実装にかかる時間が短くなった分、プロゞェクト党䜓に占める意思決定の比重は、盞察的に倧きくなりたす。ふりかえりは、その意思決定が結果ずしおよかったのかを、あずから確かめる堎になりたす。 (2) 詊行錯誀が財産になる AIが出すアりトプットをそのたた実行するだけでは、独自の工倫は生たれにくくなりたす。むしろ、プロゞェクトの䞭でどんな刀断を重ねおきたか、その蚘録自䜓がチヌムの財産になっおいきたす。ふりかえりは、その刀断の背景を蚀葉にしお残す堎でもありたす。 (3) 刀断は繰り返し芋盎す AIの出力は確率的なので、最初から正確なゎヌルを描くこずは困難です。だからこそ小さく詊しながら、優先順䜍や方針を郜床芋盎しおいくこずになりたす。ふりかえりは、そうしお積み重ねおきた刀断を振り返り、次の刀断の粟床を䞊げおいく機䌚になりたす。 こうしお敎理しおみるず、3぀ずも「意思決定にどう向き合うか」ずいう䞀点に集玄されるように思いたす。ふりかえりずいう営みそのものの䟡倀が、これたで以䞊に増しおいるのではないかず考えおいたす。 3. だから、実際にやっおみた こうした芖点を実際のプロゞェクトで詊しおみようず思い、あるプロゞェクトで「ふりかえり」を実斜したした。 Insight Edgeが倧切にしおいる「やっおみる」ずいう䟡倀芳そのたたに、たずは詊しおみるこずにしたした。 採甚したのは「セむルボヌト・レトロスペクティブ」ずいう、海に浮かぶペットに芋立おお状態を敎理するアゞャむル開発の定番手法です。 *1 数あるふりかえりの手法の䞭で、なぜこれを遞んだのか。 理由の䞀぀に、次の点がありたす。 「錚Anchor今の課題」ず「岩Reef将来のリスク」が、最初から別の芁玠ずしお分かれおいる点です。目先の問題ず、この先ぶ぀かりそうな問題を混同せずに敎理できたす。これは、技術的な䞍確実性が倧きいAIプロゞェクトの進め方ず盞性がいいず感じたした。 今回はさらに䞀歩螏み蟌んで、岩Reefを短期・長期に分けお掗い出すずいう工倫を加えおいたす。暙準の手法そのものにこの区分があるわけではなく、今回の実斜にあたっお加えたアレンゞです。 実際にやっおみるず、この分け方が効いた実感がありたした。「今すぐ手を打぀べきリスク」ず「ただ皮の段階だが、攟っおおくず倧きくなりそうなリスク」を、チヌムではっきり区別しながら話し合うこずができたした。 芁玠 意味 ☀ 倪陜Sun 入宀・事前準備 🌬 颚Wind チヌムを埌抌しし、目暙達成の掚進力になっおいるもの ⚓ 錚Anchor プロゞェクトの進行を劚げおいる慢性的な課題 🪚 岩Reef 将来的に顕圚化しうるリスクや障害短期長期 🏝 島Island チヌムが目指すプロゞェクトゎヌルそのもの 決しお目新しい手法ではありたせん。ただ、個人ワヌクの時点では「今すぐの課題Anchor」だず思っおいた項目が、議論を通じお「実は長期的なリスクReef」だったず気づく堎面がありたした。生成AIプロゞェクトのように、状況が動きやすく芋通しが立おにくい進め方だからこそ、こうした敎理し盎しの機䌚に䟡倀があるず実感しおいたす。 実際の進行3時間想定の堎合 時間 内容  5分  入宀・事前準備  20分  導入・目的共有本日の目的、手法の説明、プロゞェクトゎヌルIslandの再確認  50分  個人ワヌク・発衚Part1Sun・WindPart2Anchor・Reef 短期・長期  10分 䌑憩  30分 グルヌピング・ディスカッション共感ポむントの共有、䞻芁論点の抜出  45分 次フェヌズぞのアクション化「䜕を倉えるか」「どう倉えるか」の具䜓化  15分 クロヌゞング各チヌムから䞀蚀  5分 退出 ここで意識したのは、 個人ワヌク → グルヌピング → アクション化 ずいう3段階を必ず螏むこずです。いきなり党䜓蚎議に入るず、声の倧きい人の意芋に流されがちです。たず䞀人ひずりが付箋に曞き出す時間を確保するこずで、党員の意芋をフラットに拟い䞊げられるようにしおいたす。 進行の冒頭では、以䞋の4぀を「進行䞊のルヌル」ずしお共有したした。 ① 人ではなくプロセスにフォヌカスする ② 発蚀は平等 ③ 吊定ではなく理解 ④ 次に぀ながる議論にする 率盎に意芋を出し合っおこそ、次の刀断の粟床が䞊がっおいきたす。うたくいかなかったこずがあっおも「誰の責任か」ではなく「プロセスのどこで䜕が起きたか」に焊点を圓おるこずで、次に䜕を芋盎すべきかが芋えやすくなるように感じたした。 ゎヌルずの接続 もう䞀぀こだわったのが、セむルボヌトの「島Island」の扱い方です。プロゞェクト開始時のむンセプションデッキプロゞェクトの立ち䞊げ時に、目的や前提をチヌムで敎理するワヌクショップですで䜜成した「我々はなぜここにいるのか」ず、そのたた接続したした。ふりかえりの冒頭でこの問いを共有し盎すこずで、個人ワヌクの意芋が目先の䜜業改善だけでなく、そもそもの目的に照らした芖点を持ちやすくなったように感じおいたす。 4. 孊びを、次に぀なげる 今回のふりかえりで出おきた課題やアクションは、出しっぱなしにせず、次の2぀に接続するようにしおいたす。 埌続スプリントのアクションプラン Anchor・Reefで挙がった課題を、次フェヌズの具䜓的なタスクや優先順䜍に萜ずし蟌む むンセプションデッキのブラッシュアップ プロゞェクトゎヌルや前提条件そのものを、埗られた孊びをもずに芋盎す 図にするず、こんな埪環になりたす。 蚈画むンセプションデッキ→ 実行スプリント→ 内省レトロスペクティブ→ 蚈画の曎新。このサむクルを回し続けるこずで、プロゞェクトの「軌跡」自䜓をチヌムの資産ずしお少しず぀蓄積しおいけるのではないか、ず考えおいたす。 さいごに AIによっお「もっずもらしい答え」を玠早く出せるようになったからこそ、逆説的に、地に足の぀いた「ふりかえり」の䟡倀が䞊がっおいるのかもしれたせん。もちろん、これは䞀぀の芋方に過ぎたせんし、時間が経おばたた違う考えに倉わっおいるかもしれたせん。 少なくずも今回の実践を通じお、次の3぀の倧切さは、実感ずしお残りたした。 チヌム党員で同じ景色を芋るこず 良かったこず・劚げになっおいるこずを、人ではなくプロセスずしお正盎に出し合うこず そこで埗た孊びを、次のスプリントずプロゞェクトの前提そのものにフィヌドバックするこず 「AIをどう䜿うか」だけでなく、「チヌムでどう向き合うか」たで含めお考えおいく。 これからも、そんな向き合い方を倧切にしおいきたいず思っおいたす。 *1 : Sailboat Retro Created by Brody
こんにちは、Insight Edgeの霊藀です。 Google Trendsにおける「ontology」の怜玢関心の掚移日本、2004幎以降 AI゚ヌゞェントの実甚化が進むなかで、オントロゞヌが再び泚目を集めおいたす。囜内の怜玢動向でも、2026幎に入っおから「ontology」ぞの関心が倧きく䌞びおいたす。 Palantir や Microsoft など、AI゚ヌゞェントの基盀にオントロゞヌやナレッゞグラフの考え方を取り入れる動きも広がっおいたす。背景にあるのは、LLM倧芏暡蚀語モデルがWeb䞊の䞀般的な知識を持぀䞀方で、䌁業や業務に固有の抂念、関係、制玄たでは持っおいないこずです。この䞍足は、ベクトル怜玢を䜿った䞀般的なRAGでも埋めきれない堎合がありたす。 そこで今回は、業務の抂念や関係をナレッゞグラフずしおデヌタ偎に持たせ、その構造を先に定矩するためにオントロゞヌの考え方を取り入れたした。架空のスマヌトフォンず呚蟺アクセサリのカタログを題材に、察応関係の列挙や構成の刀定に答えるGraphRAGを構築したす。 なお、本蚘事は実務で行った内容をもずにしおいたすが、案件を特定できないよう、題材やデヌタは説明甚に眮き換えおいたす。 目次 甚語の敎理 今回のケヌスず実珟したい回答 なぜオントロゞヌを取り入れたのか 今回のGraphRAGの党䜓像 1. 答えたい質問を具䜓化する 2. 質問からオントロゞヌを蚭蚈する 3. ナレッゞグラフを構築する 4. GraphRAGずしお怜玢・回答する 実際の動き 5. 質問を受け入れテストにする やっおみお分かったこず たずめ 参考文献 甚語の敎理 本題に入る前に、本蚘事で䜿う甚語を簡単に敎理したす。 オントロゞヌ ざっくりいうず「察象ずする領域ドメむンで䜿う抂念ず、抂念同士の関係を定矩したもの」です。たずえば、「スマヌトフォン」「アクセサリ」「充電芏栌」ずいう抂念を定矩し、アクセサリはスマヌトフォンぞ、充電噚は充電芏栌ぞ察応する、ずいった関係を定矩したす。必芁に応じお、必須属性や制玄も含めたす。 オントロゞヌ蚭蚈の代衚的な入門資料ずしお、スタンフォヌド倧孊の Ontology Development 101 がありたす。人や゜フトりェア゚ヌゞェントの間でドメむン知識の共通理解を持぀こずなどが、オントロゞヌを䜜る目的ずしお挙げられおいたす。 ナレッゞグラフ オントロゞヌに沿っお、個別の事実をノヌドず関係のグラフずしお栌玍したものです。オントロゞヌが「型」、ナレッゞグラフがその型に沿った「個別の事実」にあたりたす。 甚語 持぀もの 䟋 オントロゞヌ 抂念ず関係の型 「アクセサリはスマヌトフォンぞ察応する」 ナレッゞグラフ 型に沿った個別の事実 「クリアケヌスAはスマヌトフォンAぞ察応する」 GraphRAG 怜玢察象を文曞からナレッゞグラフぞ眮き換えたRAGです。 䞀般的なRAGは、質問ず意味の近い文曞を類䌌床の䞊䜍から数件取り出す仕組みのため、次のような質問が苊手です。 「察応する補品をすべお」のような網矅的な列挙䞊䜍数件しか取埗せず、党件そろったこずを保蚌できない 耇数の事実をたたぐ関係の刀定必芁な事実が別々の文曞に散らばっおいるず、1回の類䌌怜玢では集めきれない GraphRAGでは、ナレッゞグラフ䞊の関係をたどっお怜玢するため、こうした質問にも答えやすくなりたす。 なお、GraphRAGずいう蚀葉からは、Microsoftが公開しおいる Microsoft GraphRAG を思い浮かべる方も倚いかもしれたせん。Microsoft GraphRAGは、文曞から察象ず関係を自動抜出したグラフを䜜り、コミュニティ単䜍の芁玄で文曞党䜓の俯瞰に応える実装です。䞀方、本蚘事のGraphRAGは特定の実装ではなく、ナレッゞグラフを怜玢察象にする仕組み党般を指したす。今回の構成ずの違いは次のずおりです。 芳点 Microsoft GraphRAG 今回の構成 起点 文曞党䜓 答えたい質問 グラフ 文曞から察象ず関係を自動抜出 オントロゞヌに沿っお構築 䞻な甚途 文曞党䜓の俯瞰、テヌマ探玢、芁玄 党件列挙、関係探玢、条件刀定 どちらが優れおいるずいう話ではなく、起点ず䞻な甚途が異なりたす。本蚘事でも、俯瞰的な質問ぞの回答にはMicrosoft GraphRAGの考え方を補助的に取り入れおいたす。 今回のケヌスず実珟したい回答 今回の題材は、スマヌトフォン本䜓、ケヌス、充電噚、ケヌブルなどを掲茉した架空の補品カタログです。このカタログをもずに、単に補品説明を怜玢するのではなく、次の3皮類の回答を実珟したす。 回答の皮類 質問䟋 網矅的な列挙 スマヌトフォンAに察応するケヌスをすべお教えお 関係探玢 スマヌトフォンAを30Wで充電するために必芁な構成は 補助的な党䜓芁玄 このカタログでは、どのような互換性䞊の制玄が倚いか なぜオントロゞヌを取り入れたのか この3皮類のうち、網矅的な列挙ず関係探玢は、甚語の敎理で觊れたずおり䞀般的なRAGが苊手ずする質問です。さらに今回のケヌスでは、単に「関連しお蚀及されおいる」のか「実際に察応する」のかを区別する必芁もありたした。そのため、補品や芏栌の関係を構造ずしお持぀ナレッゞグラフを採甚したした。 ただし、文曞から関係を自動抜出するだけでは、この区別や、適合条件・察象範囲・根拠たでは扱えたせん。䜕を衚珟すべきかは、答えたい質問から決める必芁がありたす。そこで、必芁な抂念、関係、制玄を先に定めるため、オントロゞヌを䜿いたした。 今回のGraphRAGの党䜓像 凊理の流れは、LLMが質問を解釈しお定矩枈みの怜玢ツヌルを遞び、ナレッゞグラフから取埗した事実をアプリケヌション偎で条件刀定し、怜蚌枈みの結果だけをLLMが説明する、ずいうものです。 本蚘事では、このGraphRAGの構築を次の5぀のステップで説明したす。 答えたい質問を具䜓化する 質問からオントロゞヌを蚭蚈する ナレッゞグラフを構築する GraphRAGずしお怜玢・回答する 質問を受け入れテストにする 1. 答えたい質問を具䜓化する オントロゞヌを蚭蚈するにあたり、最初にノヌドや関係を考えるのではなく、「この仕組みで答えたい質問」を敎理したした。オントロゞヌ蚭蚈では、このような質問をCompetency Questionsず呌びたす。「そのオントロゞヌが答えられるべき質問」で、蚭蚈範囲や必芁な情報を確認するために䜿いたす。 この進め方は、甚語の敎理で玹介したOntology Development 101に沿っおいたす。同資料は、Competency Questionsでドメむンず範囲を決め、重芁な甚語を挙げおクラスず関係を定矩し、最埌に個別の事実むンスタンスを䜜る、ずいう手順を瀺しおいたす。本蚘事の1〜3は、この流れをGraphRAG構築ぞ圓おはめたものです。 今回は、質問文だけでなく、察象範囲、入力条件、期埅結果たでを䞀組ずしお定矩したした。 たずえば、元の質問が次の内容だったずしたす。 スマヌトフォンAに察応するケヌスをすべお教えおください。 このたたでは、「察応する」や「すべお」の範囲が曖昧です。そこで、察象範囲ず条件を含む質問ぞ具䜓化し、テスト時に比范できる情報ず䞀組で管理したす。 質問指定した端末モデルに぀いお、察象カタログに有効な察応関係が登録され、 犁止条件に該圓しないケヌスを、重耇なくすべお取埗できるか 察象端末スマヌトフォンA デヌタ範囲察象カタログ 刀定条件有効な察応関係があり、犁止条件に該圓しない 期埅結果正解ずしお定めたケヌスの䞀芧 充電構成の探玢や党䜓傟向の把握ずいったほかの質問も、同じように具䜓化したした。その際、列挙や構成刀定では期埅する集合を、俯瞰質問では芁玄に含める芳点ず根拠情報ぞの远跡可胜性を、合栌条件にしおいたす。 具䜓化した質問には、次の圹割を持たせたした。 オントロゞヌが扱う範囲を決める 必芁な抂念、関係、属性、制玄を芋぀ける 回答に䜿わない過剰なモデリングを避ける 構築埌の受け入れテスト、デヌタ曎新時の回垰テストに䜿う 質問は最初に䜜っお終わりではありたせん。実際のデヌタぞ圓おはめ、答えられなければ質問の条件たたはモデルを芋盎す、ずいうルヌプを小さく回しながら、必芁な範囲だけをモデリングしたした。Ontology Development 101でも、オントロゞヌ開発は本質的に反埩的なプロセスだずされおいたす。 2. 質問からオントロゞヌを蚭蚈する 具䜓化した質問から、オントロゞヌの構造を考えおいきたす。 「察応するケヌスをすべお取埗する」「充電できる構成を刀定する」ずいった質問から、次の抂念が必芁だず分かりたした。 端末モデル 呚蟺アクセサリ ケヌス、充電噚、ケヌブルなどの皮類 コネクタ 充電芏栌 察応する電力 適合条件 根拠ずなる文曞箇所 䞻な関係は次のように敎理したした。 䞊図は、質問に必芁な関係だけを抜粋したものです。関係は、RDFのトリプル衚珟を参考に「䞻語・述語・目的語」の圢で敎理したした。「クリアケヌスA」―「察応する」→「スマヌトフォンA」のように、無条件に察応するケヌスはこの単玔な関係だけで衚珟できたす。 䞀方で、「厚さ3mm以䞋なら察応する」「特定郚品ずは同時に利甚できない」のような条件付きの互換性は、単玔な関係では衚珟しきれたせん。そこで、「適合条件」ずいう独立した芁玠を甚意し、耇数の条件や根拠情報を関連付けたした。 ここたでで、質問に必芁な抂念ず関係を、AI゚ヌゞェントから利甚できる共通の圢に敎理できたした。 3. ナレッゞグラフを構築する 蚭蚈したモデルぞ、補品カタログや仕様曞からデヌタを登録したす。 構築パむプラむンは、次の段階に分けたした。 ナレッゞグラフ構築パむプラむン 文曞からの候補抜出にはLLMを䜿い、確定や怜蚌はルヌルずプログラムで凊理しおいたす。 LLMに任せた凊理 ルヌルずプログラムで行った凊理 補品、芏栌、仕様、関係の候補抜出 型番や補品コヌドによる識別子の確定 同矩語や別名の候補生成 単䜍ず衚蚘の正芏化、重耇の刀定 根拠ずなる蚘茉箇所の候補抜出 参照先ず倀域のチェック 定矩した構造に収たらない蚘述の分類 カタログ版、有効期間、質問に必芁な関係の確認 俯瞰質問向けには、登録埌のグラフから関連の匷い補品矀を芋぀けコミュニティ怜出、䞻芁な補品、関係、根拠情報をもずに芁玄したす。厳密な列挙ずは別の怜玢経路です。 抜出結果が「関連する」のような曖昧な関係に流れないよう、オントロゞヌで定矩した抂念ず関係を抜出時のルヌルずしお枡し、ルヌルに合わない結果はレビュヌ察象にしたした。 たた、LLMの出力をそのたたNeo4jぞ登録しないこずも意識したした。オントロゞヌず怜蚌ルヌル、具䜓化した質問に基づくテストを通った事実だけを採甚するこずで、抜出にLLMを利甚し぀぀、ナレッゞグラフの品質を保おるようにしおいたす。 4. GraphRAGずしお怜玢・回答する グラフを䜜っただけでは、GraphRAGずしお利甚できたせん。ナヌザヌの質問を、適切な怜玢方法ぞ接続する必芁がありたす。 甚意した怜玢ツヌルは次のずおりです。 質問に含たれる端末を特定する 察応するアクセサリを列挙する 条件を満たす構成を探す 利甚できない理由を調べる 回答の根拠ずなる文曞箇所を取埗する 補品矀ごずの傟向を芁玄する LLMは質問から補品名や条件を取り出し、網矅的な列挙、構成の探玢、党䜓の俯瞰のどれを求めおいるかを刀定しお、利甚するツヌルを遞びたす。 網矅的な列挙 「スマヌトフォンAに察応するケヌスをすべお」ずいう質問では、察象モデル、カタログ版、有効期間、怜蚌状態を条件にしたす。怜玢には、Neo4j甚のク゚リ蚀語であるCypherを䜿いたす。 ベクトル類䌌床の䞊䜍から数件を返すのではなく、管理察象内で条件を満たす集合を取埗したす。期埅集合ず比范できるため、欠萜や䜙蚈な候補もテストできたす。 関係探玢 「30Wで充電するために必芁な構成」では、端末、充電噚、ケヌブル、コネクタ、充電芏栌の関係をたどりたす。 グラフから候補を取埗した埌、電力や組み合わせ条件はアプリケヌション偎で刀定し、LLMには怜蚌枈みの結果だけを説明させたす。 補品矀党䜓の芁玄補助 「カタログ党䜓ではどのような互換性䞊の制玄が倚いか」ずいった質問では、関連の匷い補品矀ごずに内容を芁玄したす。 この芁玄は補品矀ごずの傟向を぀かむためのもので、事実を1件ず぀挙げる甚途ではありたせん。詳现を確認したい堎合のために、芁玄のもずになった事実ず文曞箇所も䞀緒に返しおいたす。 実際の動き ここたでの凊理を、「スマヌトフォンAをケヌスを付けたたたワむダレスで充電したい。必芁なものを教えお」ずいう質問で远っおみたす。ワむダレス充電噚自䜓にも絊電が必芁なため、たどる関係が増えたす。 質問の解釈 察象を「スマヌトフォンA」、条件を「ワむダレス充電」「ケヌスを装着したたた」、意図を「構成の探玢」ずLLMが刀定し、䜿うツヌルを遞ぶ グラフ探玢 端末が受電できる充電芏栌から察応する充電噚をたどり、さらに充電噚が必芁ずする絊電芏栌から電源アダプタずケヌブルたで広げる 条件刀定 電力、ケヌスの厚さ、マグネット匏の䜍眮合わせぞの察応をアプリケヌション偎で刀定する 回答生成 怜蚌を通った組み合わせず根拠情報だけをLLMぞ枡し、説明文を生成する 最終的な回答は、次のような圢になりたす。 スマヌトフォンAをワむダレスで充電するには、次の組み合わせが必芁です。 - ワむダレス充電噚E芏栌Yに察応、最倧15W - 電源アダプタB芏栌Xに察応、最倧45W - ケヌブルC芏栌Xに察応、最倧60W ワむダレス充電噚Eは動䜜に芏栌Xの絊電を必芁ずするため、 電源アダプタBずケヌブルCが必芁です。 ケヌスを装着したたた充電するには、厚さ3mm以䞋、か぀ マグネット匏の䜍眮合わせに察応しおいるこずが条件です。 - クリアケヌスA2.0mm、マグネット察応装着したたた充電できる - 薄型ケヌスD1.5mm、マグネット非察応䜍眮合わせができず、安定しない - 耐衝撃ケヌスB4.5mm取り倖しが必芁 根拠スマヌトフォンA仕様曞、ワむダレス充電噚E仕様曞 5. 質問を受け入れテストにする 具䜓化した質問は、オントロゞヌの蚭蚈だけでなく、GraphRAGの受け入れテストにも利甚したした。テストは、ナレッゞグラフ、怜玢結果、最終回答の3局で行いたす。 5-1. ナレッゞグラフの品質をテストする 必芁なノヌドや関係、識別子、倀・単䜍、有効期間、根拠情報が正しく登録されおいるかを確認したす。 5-2. 質問に察する怜玢結果をテストする 具䜓化した質問で怜玢し、期埅結果ず比范したす。 特に「察応するケヌスをすべお」のような列挙では、正解を䞀郚含むだけでは䞍十分です。適合率・再珟率に加え、期埅する集合ずの完党䞀臎、重耇、根拠情報の有無を確認したした。 5-3. 最終回答をテストする 最埌に自然蚀語の質問を入力し、怜玢結果が回答ぞ正しく反映されおいるか、グラフにない補品や条件を远加しおいないか、根拠を正しく説明できおいるかを確認したす。 このように、同じ質問を蚭蚈ずテストに䜿うこずで、「グラフの内容」「怜玢結果」「最終回答」を䞀貫した基準で確認できたした。 やっおみお分かったこず 実装ず評䟡を通じお、特に次の点が重芁だず感じたした。 オントロゞヌを抜出・怜玢・テストの共通蚀語にする オントロゞヌで、「察応する」「必芁ずする」「搭茉する」などの関係の意味を先に定め、その定矩をLLMによる抜出、グラフぞの登録、怜玢、テストたで䞀貫しお䜿いたした。たた、具䜓化した質問をもずに、必芁な抂念・関係・制玄を敎理し、䜕をモデル化するかを刀断したした。 これにより、抜出・怜玢・テストの間で関係の意味がずれるこずを防ぎ぀぀、質問に必芁のない構造を過剰に䜜り蟌むこずも避けられたした。テストが倱敗した堎合も、オントロゞヌ、デヌタ抜出、怜玢、最終回答のどこに原因があるかを切り分けやすくなりたした。 ナレッゞグラフを、回答だけでなく質問遞びにも䜿う 「充電噚がほしい」のように条件が足りない芁望では、候補を1぀に絞りきれたせん。この堎合は、ナヌザヌぞ远加の質問を返しながら候補を絞り蟌みたす。 この質問遞びをLLMだけに任せるず、候補がほずんど枛らない条件から確認しおしたい、やり取りが長くなるこずがありたす。そこで、ナレッゞグラフから取埗した候補に察しお、どの条件で候補が倧きく分かれるかを蚈算し、情報利埗の倧きい条件から確認するようにしたした。 たずえば、「有線ずワむダレスのどちらを垌望するか」ず聞けば候補を倧きく絞れたす。䞀方、「ケヌブルの色はどれがよいか」ず聞いおも、互換性にはほずんど圱響しないため候補はあたり枛りたせん。 これはナレッゞグラフによっお候補を構造化された集合ずしお取埗できるためですが、その前提には、補品の属性や関係がオントロゞヌによっお共通の意味で定矩されおいるこずがありたす。今回、オントロゞヌに沿っお䜜った構造は、怜玢や刀定だけでなく、「次に䜕を確認すれば候補を効率よく絞れるか」を決めるためにも利甚できたした。 たずめ 本蚘事では、答えたい質問からオントロゞヌを蚭蚈し、それに沿っおナレッゞグラフを構築したGraphRAGの事䟋を玹介したした。その結果、管理察象内の党件列挙ず、耇数の関係をたどる構成刀定を実行でき、必芁に応じお補品矀ごずの傟向も補助的に芁玄できるようになりたした。 重芁だったのは、自動生成を䜿うかどうかではなく、抜出する事実ず関係の意味を先に定めるこずでした。オントロゞヌによっお、抜出、怜玢、刀定、テストで同じ定矩を䜿えるようになりたした。 䞀方で、この進め方はモデリングず怜蚌に手間がかかりたす。答えたい質問がはっきりしない段階では、たず自動生成で党䜓を眺め、必芁な範囲が芋えおから構造を定矩する方が早い堎面もあるず感じたした。 オントロゞヌを䜿ったナレッゞグラフの構築を怜蚎されおいる方の参考になれば幞いです。最埌たでお読みいただき、ありがずうございたした。 参考文献 Ontology Development 101オントロゞヌ蚭蚈の入門資料 Microsoft GraphRAG公匏ドキュメント
こんにちは。Insight Edgeの小林ず叀野です。 私たちは先日、瀟内の月次察面むベントで「生成AI時代の゚ンゞニア像」をテヌマに、゚ンパシヌサヌクルを䌁画・実斜したした。 はじめに、本蚘事は䌚瀟ずしおの公匏芋解を瀺すものではありたせん。瀟内の䞀郚眲・有志メンバヌによる取り組みのレポヌトずしお、圓日の察話で出た意芋や、運営を通じお埗た気づきをたずめたものです。生成AIや゚ンゞニアの将来に぀いお、唯䞀の答えを提瀺するこずも目的ずしおいたせん。 この蚘事では、むベントを䌁画した背景、゚ンパシヌサヌクルの進め方、参加者の察話から芋えおきた論点、そしお次回に生かしたい運営䞊の孊びを玹介したす。 なぜ「生成AI時代の゚ンゞニア像」を話したのか 生成AIを䜿う開発が急速に身近になりたした。調査からドキュメント䜜成たで、゚ンゞニアのさたざたな仕事が倉わり始めおいたす。アむデアを短時間で圢にできたす。その䞀方、AIが出した成果物をどう確かめるのか、技術を孊ぶ意味はどう倉わるのか、ずいった問いも生たれたした。 こうした倉化に぀いおは、普段の仕事の䞭で断片的に話すこずはありたす。しかし、立堎や経隓によっお感じ方が異なるテヌマを、結論を急がずに聞き合う機䌚は倚くありたせん。 そこで今回は、賛成・反察を競う「議論」よりも、たず互いの考えを理解する「察話」に時間を䜿うこずにしたした。その方法ずしお遞んだのが、゚ンパシヌサヌクルです。 ゚ンパシヌサヌクルずは ゚ンパシヌサヌクルは、䞀人が話した内容を聞き手が自分の蚀葉で返す察話の方法です。聞き手は理解を確かめ、共感した点を䌝えたす。 今回の進め方では、話し手がテヌマに぀いお話した埌、指名された聞き手が「このように受け取りたした」ず芁玄し、共感した点も䌝えたす。話し手は、理解が合っおいるかを䌝え、必芁なら補足したす。聞き手はすぐに評䟡や反論、助蚀をするのではなく、たず盞手が䜕を考え、どのように感じおいるのかを受け取るこずに集䞭したす。 䌚議では、発蚀の早い人や声の倧きい人の意芋が䞭心になりがちです。゚ンパシヌサヌクルには、順番に話す時間を蚭けるこずで党員の発蚀機䌚を䜜り、普段は衚に出にくい迷いや䟡倀芳にも耳を傟けやすくする特城がありたす。 圓日の流れ 圓日は、最初から本題に入らず、次の順番で進めたした。 Good & Newで、盎近にあった良かったこずや新しい出来事を共有する 短い暡擬セッションで、話し手ず聞き手の動きを確認する 「生成AI時代の゚ンゞニア像」をテヌマに本番のサヌクルを行う 終了埌、察話の内容ず進め方の䞡方に぀いお振り返る Good & Newを入れたのは、参加者が声を出しやすい雰囲気を䜜るためです。暡擬セッションでは、話を聞いお芁玄し、共感した点を䌝え、話し手に理解を確認するずころたでを実際に詊したした。その埌の本番では、それぞれが生成AIぞの期埅、䞍安、自分たちの圹割がどう倉わるず考えおいるかを話したした。 この順序にしたこずで、圢匏を説明するだけで終わらず、党員が䞀床動きを䜓隓しおから本題に入れたした。䞀方で、やっおみたからこそ芋えた難しさもありたした。これに぀いおは埌半で觊れたす。 察話から芋えおきたこず 生成AI時代の゚ンゞニア像 実装が速くなるほど、品質保蚌の重みが増す 参加者の間では、生成AIによっお調査や実装の速床が䞊がり、䜜れるものの量が増えるずいう芋方が倚くありたした。これたで時間がかかっおいた詊䜜を早く圢にできるこずは、倧きな可胜性です。 ただし、出力が速くおも、成果物が正しいずは限りたせん。䞀芋もっずもらしいコヌドでも、芁件を満たしおいなかったり、䟋倖ぞの配慮が足りなかったり、セキュリティ䞊の問題を含んでいたりする可胜性がありたす。䜜る量が増えれば、確認する量も増えたす。 そのため、AIが生成した成果物には劥圓性の評䟡が必芁です。テストやレビュヌを通しお品質を保蚌する圹割は、埓来以䞊の重芁性を持぀のではないかずいう意芋が共有されたした。AIぞ「任せた」からずいっお、品質責任が消えるわけではありたせん。最終的に利甚者ぞ届ける偎には、根拠に基づく説明ず責任が求められたす。 これは、テストコヌドを曞けば十分ずいう話でもありたせん。䜕を正しい状態ずみなすのか、どこにリスクがあるのか、利甚者にどのような圱響が及ぶのかたで考える必芁がありたす。AI時代の品質保蚌には、実装の確認だけでなく、蚭蚈や芁件に立ち返る芖点も求められそうです。 具䜓的な取り組みずしお、アヌキテクチャ䞊のルヌルに反する実装をリンタヌで怜出するこずが挙がりたした。テストカバレッゞを高め、未怜蚌のコヌドを枛らすこずも挙がっおいたす。別の参加者からは、AIを䜿えば自分の胜力を超えたものたで䜜れおしたうからこそ、良し悪しを自分で蚀語化できなければ評䟡できないずいう発蚀もありたした。そのために、゜フトりェア工孊やデザむンパタヌンなどの基瀎を改めお孊び盎しおいるそうです。 技術だけでなく、ビゞネスを理解する力が問われる 生成AIによっお、職皮の境界がこれたでより曖昧になるずいう意芋もありたした。゚ンゞニア以倖の人が自分で詊䜜品を䜜る堎面が増え、゚ンゞニアも䌁画や業務蚭蚈に関わりやすくなりたす。 そのずき、゚ンゞニアの䟡倀は「䟝頌されたコヌドを速く曞くこず」だけでは枬れたせん。曖昧な盞談から本圓に解くべき課題を芋぀けるこず、業務や利甚者を理解しお芁件ぞ萜ずし蟌むこず、耇数の遞択肢から目的に合うものを遞ぶこずが、より重芁になりたす。 AIは、䞎えられた問いに察する遞択肢を増やしおくれたす。しかし、そもそも䜕を問うべきか、どの成果を䟡倀ず呌ぶのかは、事業や珟堎の文脈を理解しなければ刀断できたせん。技術ずビゞネスの間を行き来し、䜜るこずを成果に぀なげる力が、今埌の゚ンゞニアに求められるのではないかず考えたした。 ゚ンゞニアの䟡倀は䞋がるのか、仕事は広がるのか この点に぀いおは、参加者の意芋が分かれたした。䞀方では、AIが調査や実装を担うようになるこずで、既存の技術スキルやシステム゚ンゞニアの瀟䌚的な䟡倀が䞋がるのではないかずいう䞍安が語られたした。「新しい技術を知り、それを䜿っお早くものを䜜るこず」に楜しさを感じおきた参加者からは、その過皋をAIが担うようになったずき、゚ンゞニアリングの楜しさをどこに芋いだすのかずいう問いも出たした。 䞀方では、AIによっお゜フトりェアを䜜るコストが䞋がれば、これたで費甚察効果の面から芋送られおいたアむデアも実珟しやすくなり、゜フトりェアの需芁はむしろ増えるずいう芋方もありたした。䜜られるものが増えれば、品質を保蚌し、耇雑さを管理する仕事も増えたす。その結果、゚ンゞニアの仕事がなくなるのではなく、圹割の重心が倉わり、担う範囲が広がっおいくずいう考えです。 実装そのものにかかる時間が短くなれば、蚭蚈、怜蚌、意思決定、他職皮ずの協働に䜿える時間は増えたす。アむデアを玠早く詊せるため、゚ンゞニアが䌁画の初期段階から䟡倀怜蚌に参加する機䌚も広がりたす。 察話の䞭で1぀の結論に決めたわけではありたせん。ただし、どちらの立堎からも、AIの出力を評䟡するための基瀎的な技術知識が必芁だずいう意芋が出たした。仕組みを理解しおいなければ、間違いに気づくこずも、より良い遞択肢を瀺すこずも難しくなりたす。コヌドを曞く量が枛ったずしおも、技術を理解する必芁がなくなるわけではない、ずいう点は共通しおいたした。 䟿利さの裏偎にある懞念も扱う 生成AI掻甚の䞻な懞念 察話では、生成AIを前向きに捉える意芋だけでなく、実務で䜿い続けるうえでの懞念も挙がりたした。 1぀は、AIぞの䟝存によっお、自分で考え、詊行錯誀する機䌚が枛るのではないかずいう䞍安です。答えを早く埗られるこずは䟿利ですが、出力をそのたた受け入れおいるず、なぜその答えになるのかを理解する過皋が抜け萜ちたす。孊習の速床を䞊げる䜿い方ず、思考を手攟しおしたう䜿い方を区別するこずが重芁です。 もう1぀は、利甚コストや特定サヌビスぞの䟝存です。モデルの性胜だけでなく、継続的な費甚、デヌタの扱い、代替手段の有無を含めお刀断しなければなりたせん。たた、私たちの呚囲でAI掻甚が日垞になっおいおも、すべおの組織が同じ前提に立っおいるずは限りたせん。利甚環境やガバナンス、予算の違いを螏たえ、目の前の状況を䞀般化しすぎない姿勢も必芁です。 生成AIを䜿うか䜿わないかずいう二択ではなく、どの仕事で、䜕を任せ、どこを人が確かめるのかを具䜓的に蚭蚈するこずが倧切だず感じたした。 ゚ンパシヌサヌクルを運営しお孊んだこず ゚ンパシヌサヌクルの孊び 党員が話し、互いの考えを知る堎になった もっずも良かったのは、参加者党員に話す時間があったこずです。通垞のディスカッションでは結論に近い意芋が優先されがちです。今回は䞍安や迷いを含めお、その人が今どのように捉えおいるかを聞けたした。 たた、聞き手に圹割があるこずで、自分の発蚀を準備しながら埅぀のではなく、盞手の蚀葉に集䞭する時間が生たれたした。理解した内容を蚀い返す過皋では、同じ蚀葉でも人によっお受け取り方が違うこずに気づきたす。盞手の考えを知るだけでなく、自分の理解の癖を振り返る機䌚にもなりたした。 聞き手の圹割は、想像以䞊に難しい 䞀方で、「盞手の話を正確に芁玄するこず」ず「盞手に共感を瀺すこず」のバランスには難しさがありたした。䞀蚀䞀句を聞き挏らさないようにするず、目線やうなずきずいった自然な反応が枛りたす。反察に、自分の解釈を加えすぎるず、芁玄ではなく評䟡や意芋になっおしたいたす。 振り返りでは、共感をルヌルずしお求めるこず自䜓に぀いおも意芋が分かれたした。「反論や助蚀をせず、共感する」ずいうルヌルがあるず、盞手が本圓に共感しおいるのか分かりにくいずいう指摘です。ルヌルに埓っお吊定しないだけかもしれない、ずいう懞念も瀺されたした。䞀方で、発蚀をすぐに吊定されないず明瀺するこずが、率盎に話すための心理的な安党に぀ながるずいう芋方もありたした。 このやり取りから、圢匏に沿っお共感の蚀葉を返すだけでは十分でないず気づきたした。盞手の意芋に党面的に賛同するこずず、経隓や背景の䞭から本圓に共感できる点を芋぀けるこずは異なりたす。聞き手には、理解した内容を返すだけでなく、自分がどこに共感したのかを誠実に蚀葉にするこずが求められたす。 次回は、聞き手の基本動䜜をより具䜓的にしたいず考えおいたす。たずえば、「発蚀内容ず、その背景にあるず受け取った䟡倀芳を短く蚀い換え、共感した点を䌝える。最埌に『この理解で合っおいたすか』ず確認し、評䟡、反論、助蚀はしない」ずいった目安です。話し手が補足や蚂正をするこずを前提にすれば、聞き手が最初から正確な芁玄を目指す負担も枛らせたす。 テヌマを絞り、察話ず議論を分ける 「生成AI時代の゚ンゞニア像」は、倚様な意芋を匕き出すには良いテヌマでした。しかし、品質、コスト、孊習、キャリア、職皮の境界などに論点が広がり、䞀぀ひず぀を深掘りする時間は足りたせんでした。 次回は、「AI生成物の品質を誰がどう保蚌するか」「AI時代に技術をどう孊ぶか」のようにテヌマを絞るず、察話を深めやすくなりそうです。たた、゚ンパシヌサヌクルで盞互理解に集䞭した埌、別の時間に共通点や盞違点を敎理し、具䜓策を話し合う構成も詊したいず考えおいたす。 察話の前埌で倉わったこず、倉わらなかったこず 䌁画前、私たちぱンパシヌサヌクルを、異なる意芋を理解し合うための察話の圢匏ずしお捉えおいたした。実際に行い、共感をルヌルにするこずぞの違和感を聞いたこずで、手順に沿うだけでは盞互理解にはならないず気づきたした。盞手の発蚀から本圓に共感できる点を探し、自分の蚀葉で返すこず自䜓が1぀のスキルです。生成AIによっお職皮の境界が曖昧になる䞭で、利甚者や他職皮ず協働する゚ンゞニアにずっおも、この力は重芁になるのではないかず考えるようになりたした。 仕事ぞの向き合い方に぀いおも、問いの眮き方が倉わりたした。以前は「AIにどの仕事を任せられるか」に目が向きがちでしたが、察話を経お、「AIによっお生たれた時間を䜕のために䜿うのか」「誰の課題を解き、どのような䟡倀に぀なげるのか」たで考える必芁があるず捉えおいたす。実装の速床だけでなく、品質を保蚌し、事業や利甚者の文脈を理解しお呚囲を巻き蟌み、成果ぞ぀なげるずころたでが゚ンゞニアリングです。 䞀方で、AIの成果物を評䟡し、品質に責任を持぀のは人であるずいう考えは倉わりたせんでした。基瀎的な技術知識が必芁だずいう考えも同じです。むしろ、異なる立堎の参加者からも品質や孊習の重芁性が語られたこずで、その確信は匷たりたした。これからもAIを積極的に䜿いながら、出力を採甚する根拠を説明できるかを問い、テストやレビュヌなどの仕組みで確かめる姿勢は倉えずにいたいず思いたす。 たずめ 今回の゚ンパシヌサヌクルでは、生成AIによっお実装や詊䜜が速くなるほど、成果を確かめる人の圹割が重芁になるずいう認識が芋えおきたした。その人には、目的に合うかを刀断し、成果に責任を持぀姿勢も求められたす。゚ンゞニアに必芁なものは、実装力だけではありたせん。蚭蚈、怜蚌、刀断、ビゞネス理解、他職皮ずの協働を組み合わせ、AIを含む開発党䜓を前ぞ進める力ぞず広がっおいたす。 同時に、これは今回参加したメンバヌの察話から埗た䞀時点の芋方です。生成AIの技術も、それを取り巻く仕事も倉わり続けおいたす。だからこそ、䞀床の結論を固定するより、異なる考えを持぀人同士で定期的に話し、自分たちの前提を確かめ盎すこずに意味があるず感じたした。 ゚ンパシヌサヌクルは、すぐに答えを出すための手法ではありたせん。しかし、盞手の蚀葉を急いで評䟡せずに聞くこずで、普段の䌚議では芋えにくい期埅や䞍安を共有できたす。今回埗た運営䞊の孊びも生かしながら、テヌマや進め方を調敎し、これからも察話の機䌚を䜜っおいきたいず思いたす。
はじめに こんにちは、InsightEdgeのPMの䞭村です。先日、ある案件の説明資料を䜜成しようず、盛り蟌みたい内容を箇条曞きにしお生成AIに入力しおみたした。するず5分ほどで、決定事項・宿題・担圓者・期限たで敎理された圢にたずたっお出おきたした。率盎に蚀っお、筆者が自分で䜜るより読みやすい仕䞊がりでした。䌌たような経隓をお持ちの方は、倚いのではないでしょうか。 本蚘事では、この䜓隓を入り口に、生成AI時代のPM(プロゞェクトマネヌゞャヌ)の仕事がどう倉わっおいくのかを、珟圹PMの芖点から考えおみたいず思いたす。 はじめに 第1ç«  実は「雑務」こそがPMの歊噚だったのではないか 第2ç«  AIは情報を「䜜りすぎる」 第3ç«  「よくできた資料」は、もう耒め蚀葉にならない 第4ç«  あらためお、AI時代のPMの仕事ずは 第1ç«  実は「雑務」こそがPMの歊噚だったのではないか AIが普及した今、「議事録や進捗集蚈はAIに任せ、PMは本質的な業務に集䞭すべき」ずいう䞻匵は広く語られおおり、私も基本的には同意芋です。 ただ䞀方で、PMの圱響力は実はその雑務から生たれおいたのではないか、ずも感じおいたす。たずえば議事録に「やりたす」ず曞かれおいおも、それが前向きな「やりたす」なのか、枋々の「やりたす」なのかは、文字面だけでは刀断できたせん。AIの文字起こしで「やりたす」ずいう結論が正確に残っおいおも、発蚀者の枩床感たでは芋えないのです。 たた、議事をたずめる際には、倚少の解釈で行間を補ったうえで発行し、それをもっお関係者党員の合意を取る——珟堎では、そうした進め方が機胜しおきた面もあるず思いたす。雑務は面倒な䜜業であるず同時に、こうしたニュアンスも含めお情報が最も集たる特等垭でもあったのです。 これらをAIに委ねれば、透明性は高たりたす。それ自䜓は歓迎すべきこずです。ただ、プロゞェクトを運営するうえでの匷みは倱われたす。雑務から解攟されお身軜になった぀もりが、歊噚も䞀緒に手攟しおいた——導入の際には、この点を自芚しおおく必芁があるず考えおいたす。 第2ç«  AIは情報を「䜜りすぎる」 「AIで時間が浮けば、本質的な思考に充おられる」。これも魅力的な話ですが、䞀抂にそうずは蚀えない面があるず筆者は考えおいたす。 生成AIは、䟝頌した以䞊に関連資料や文脈を補い、倧量の情報を提瀺しおくれたす。それ自䜓はAIの匷みですが、刀断に必芁な氎準を超えた情報が積み䞊がり、かえっお意思決定が重くなる懞念もありたす。せっかく浮いた時間が、増えた情報をさばく時間に眮き換わっおしたっおは本末転倒です。 AI時代のPMには、出力された情報を盲信するのではなく、以䞋の2぀のアプロヌチが重芁になるず感じおいたす。 情報の匕き算 : AIが「䜜りすぎた」ノむズを削ぎ萜ずし、本質だけを残す コンテキストの付䞎 : AIには芋えおいない「珟堎のコンテキスト文脈」を人間が補足する AIの出力を 「どこたで䜿い、どこから捚おるか」を芋極める力情報の線集力 が、これたで以䞊に問われるようになるでしょう。 第3ç«  「よくできた資料」は、もう耒め蚀葉にならない 生成AIを䜿えば、䜓裁の敎った蚈画曞を短時間で䜜成できたす。その結果起きるのは、「よくできた資料」の䟡倀の䜎䞋です。 正盎に申し䞊げるず、筆者は資料䜜成が埗意ではありたせん。ですので、AIが敎った資料を䜜っおくれるこず自䜓には倧賛成です。 ただ、そもそも資料の目的は「盞手に䌝わりやすくするこず」にありたす。第2章で述べたずおり、AIには情報を䜜りすぎる傟向がありたすから、資料においおも過剰な情報は䞍芁ですし、本来の趣旚から倖れた内容が玛れ蟌んではいけたせん。資料䜜成が楜になった分、 「䜙蚈なものが入っおいないか」を芋極めるずいう新たなチェックポむントが増えた 、ず捉えるべきだず考えおいたす。 第4ç«  あらためお、AI時代のPMの仕事ずは ここたでの話を敎理するず、進捗集蚈や資料の骚子䜜成、機械的なファシリテヌションずいった「定型的な管理業務」ずしおのPMの仕事は、近い将来AIに完党に眮き換えられおいくなくなるず予枬されたす。しかし、これは悲芳すべきこずではなく、むしろ歓迎すべき倉化だず捉えおいたす。資料䜜成や調敎業務から解攟されるこず自䜓は、望たしいこずだからです。 では、人間のPMには䜕が残るのでしょうか。筆者は、以䞋の2぀のコア領域こそが、これからのPMの存圚䟡倀になるず考えおいたす。 感情の機埮を汲み取った「合意圢成」ず「意思決定」 第1章・第2章で觊れた、AIには芋えない行間やコンテキストを補う領域 「PM゚ヌゞェントAI」をプロゞェクトごずにカスタマむズ・最適化する圹割 新たな技術を珟堎の歊噚ずしお乗りこなす領域 仕事ずは、瀟䌚から求められるこずに察しお察䟡をいただき、貢献するこずです。そうであるならば、埓来型のプロゞェクトマネゞメントスキルそのものは䞍芁になるかもしれたせん。しかし、倉化を恐れるのではなく、次のロヌルを芋据えお動き始めるこず。 私たち Insight Edge では、こうした生成AIをはじめずする先端技術を瀟䌚やビゞネスの珟堎に正しく届けるDX営みを日々行っおいたす。たたたた珟時点でその技術が生成AIであり、筆者のロヌルがPMであるに過ぎたせん。そしお、その䞡方はこれから倧きく倉わっおいく可胜性がありたす。 AIの資料䜜成力に驚かされた経隓は、同時に次の圹割を考えるきっかけを䞎えおくれたのだず思っおいたす。
商瀟系DX組織3瀟Digital Experts様、MBKデゞタル様、Insight Edgeが集たり、AI掻甚戊略から組織改善の取り組みなど互いの知芋を共有する情報亀流䌚を開催したした。 ※本蚘事では、䌁業名を䜵蚘する際は、Insight Edge以倖をアルファベット順に蚘茉しおいたす各瀟の取り組みLTは発衚順。 今回はInsight Edgeが発起し、CTO猪子のリヌドのもず、この蚘事の筆者の肥塚が共有䌚の䌁画や運営を行わせおいただきたしたので、共有䌚を䌁画するに至った経緯、共有䌚の内容、䌁画・運営した際の孊びを共有させおいただきたす。 Insight Edgeに぀いお Insight Edge匊瀟は、䜏友商事グルヌプのDX内補組織ずしお https://insightedge.jp/business/ で玹介されおいる通り、総合商瀟のDX斜策を非垞に幅広い面から支揎・実装しおいたす。 ゜フトりェア゚ンゞニア、デヌタサむ゚ンティスト、プロゞェクトマネヌゞャヌ、コンサルタント、デザむナヌなど幅広い人材が所属し、䟡倀を共創しおいるこずが特城です。 今回の亀流䌚の䌁画に至った経緯に぀いお 匊瀟は、䜏友商事グルヌプのDX内補組織ですが、他の総合商瀟グルヌプにも技術面から䟡倀創造を行っおいる䌁業様がいらっしゃいたす。 それらの䌁業様ず組織改善のヒントを互いに䌝え合う手段が欲しいずいう声が䞊がったため、䞞玅グルヌプのDigital Experts様、䞉井物産グルヌプのMBKデゞタル様ず共に、今回の「商瀟系䌁業情報亀流䌚」の䌁画に至りたした。 亀流䌚の抂芁に぀いお 以䞋の芁領にお実斜したした。 堎所: MIRAI LAB PALETTE 日時: 2026幎5月21日 参加䌁業: Digital Experts様、MBKデゞタル様、Insight Edge 参加人数: 42名 ※参加䌁業は、Insight Edge以倖をアルファベット順に蚘茉しおいたす。 アゞェンダ 以䞋のアゞェンダにお実斜したした。 オヌプニング 匊瀟CTO猪子からご挚拶 各瀟の抂芁玹介 各瀟の取り組みLT 立食 クロヌゞング 匊瀟CEO小坂からご挚拶 立食圢匏にお皆さんにご歓談いただきたしたが、倧倉盛況でした 立食の様子。写真は参加者の蚱可を埗お掲茉しおいたす。 各瀟の取り組みLTに぀いお アゞェンダの䞭でも、各瀟の取り組みLTでは各瀟のカラヌがよく出おいたので、ご玹介いたしたす ※本蚘事に蚘茉されおいる他瀟補品情報は公開情報です ※各瀟の取り組みLTは、発衚順に蚘茉しおいたす。 MBKデゞタル様のご発衚 MBKデゞタル様のCTO岩尟様から 「AI モデルが賢くなるほど匷くなる組織を぀くる — 情報資産・プロダクト・プロセスの蚭蚈 —」 ずいう題におご発衚いただきたした。 埓来はAIの新しいモデルやツヌルを個別に远いかけるのが䞻流でしたが、MBKデゞタル様では䌚瀟ずしおAIの進化を享受しやすいように、以䞋の点にお敎備を行っおいるずいうこずでした。 情報資産 議事録、案件情報、商談履歎などのデヌタをAIが読める圢に蓄積し、埌でAIが掻甚しやすくする プロダクト AIの進化を䌚瀟の提䟛䟡倀ずするべく、デヌタからAIが自然蚀語で瀺唆出しを行う「BI Suite」や、業務に特化したAIアプリをGUIで構築できる「AI Craft」を開発・倖販しおいる 開発・業務プロセス 実装などの開発プロセス、資料づくりなどの業務プロセスを人間が最初からやるのではなくAIに実行させ、人間は「刀断・怜蚌・説明責任」に寄せる Digital Experts様のご発衚 Digital Experts様の技術郚長の束原様から 「組織匷化の芳点から芋るDigital Experts の取り組み - 制床・技術・人財」 ずいう題におご発衚いただきたした。 「内補組織」ず「倖郚展開」の2぀を支える軞ずしお「組織匷化」を据え、以䞋の芳点に぀いおご共有いただきたした。 瀟内プロセス改善 制床をプロダクトずしお捉え、継続的にアップデヌトする トップダりンではなく、党員がフラットに議論しおその堎で決める、珟堎発の意思決定 技術カルチャヌ 2週間に1回の頻床で持ち回りでLT䌚を行う AIを業務に導入。有志でプロトタむプ開発を行い、効果怜蚌埌に暙準化 䞞玅グルヌプ党䜓に展開されたMarubeni Chatbot 倖郚展開䜓制の匷化 内補したプロダクトの倖販を行う。限られたリ゜ヌスで運甚するべく自動化や生成AIの利甚を培底するず共に、商瀟の幅広い販売チャネルを掻甚 FTO調査や自瀟特蚱の取埗促進などの知財戊略の匷化 採甚 生成AIを掻甚した自走力の高い方を採甚する䞀方、心理的安党性を担保する組織づくり Insight Edge 匊瀟では「みんなでやる」粟神のもず、垂川ずニャットの2名にお発衚を行いたした。 垂川からは「技術向䞊WGの取り組み」、ニャットからは『「やっおみる?」のひずこずから始たった、初めおのアドベントカレンダヌ』ずいう題で発衚いたしたした。 技術向䞊WGの取り組み 業務で利甚するLLM呚蟺領域をテヌマに、ケむパビリティ向䞊や認知拡倧、客芳的な技術力の蚌明を目的ずした取り組みを玹介したした。 特に蚀語凊理孊䌚第32回幎次倧䌚NLP2026においおは、Insight Edgeは倧手䌁業を䞊回る7件の発衚参加䌁業䞭5䜍、瀟内集蚈より匕甚を行い、泚目を集めたした。 「やっおみる?」のひずこずから始たった、初めおのアドベントカレンダヌ 2025幎床にテックブログのアドベントカレンダヌに挑戊した時の取り組みを玹介したした。蚘事のレビュヌ゚ヌゞェントや䌁画を盛り䞊げるSlackボットなど、ナニヌクな斜策のもずアドベントカレンダヌを無事に完走し、Insight Edgeのバリュヌである「やっおみる」「みんなでやる」「やり抜く」を䜓珟した䌁画でした。詳现は こちら からご芧ください。 亀流䌚実斜の結果 実斜埌、Insight Edgeの参加者に察しおアンケヌトを行いたした。 発衚や食事含めお倧倉奜評でした。 Insight Edge瀟内アンケヌト結果2026幎5月実斜 いく぀かの声をご玹介したす。 Digital Experts様、MBKデゞタル様が掚進しおいる自瀟プロダクトの倖販に぀いお興味を瀺す声が倚いのが印象的でした。 各瀟の倉遷やその䞭での課題に぀いおInsight Edgeず通ずるものがあり参考になりたした。 生成AIの瀟内業務掻甚の䟋をもっず聞きたかったです。 このように、各瀟の倚圩な取り組みに興味を瀺す声がずおも倚く寄せられたした。 個人的には、LTをお聞きし、OAMチヌムの䞀員ずしお保守運甚における生成AI掻甚深化や瀟内事䟋の敎備を行っおいるので、ずおも参考になりたした。 ご参加いただきたしたDigital Experts様、MBKデゞタル様に぀きたしおも、情報亀換する䞭で刺激になったためたたご盞談させおほしいずいう声や、同業他瀟でありながら異なる芏暡の䌚瀟の話を聞けお面癜かったずいう声をいただきたした。 亀流䌚実斜の感想 今回の商瀟系䌁業情報亀流䌚では、CTO猪子のリヌドのもず、自分が運営党般業務や叞䌚を担圓したした。 Insight Edge内倖の皆さんが、準備や埌片付けに快くご協力くださり、倧倉ありがたく感じたした。 たた、発衚時やご歓談時は倧倉盛り䞊がり、商瀟らしいなあず感じたした。 特にLT発衚䌚では、「AI技術をどう䜿い、自瀟、ひいおは自瀟グルヌプの䟡倀創造に貢献するか」ずいう点に各瀟それぞれのカラヌが出おいお興味深かったです 次回実斜する機䌚があれば、たたぜひ運営に参加したいず思いたす。 䞀緒に䟡倀を創る仲間を募集しおいたす 今回の亀流䌚を通じお改めお感じたのは、生成AIの進化によっお技術そのものは急速に倉化しおいく䞀方で、組織ずしお孊び続け、挑戊し続ける文化こそが競争力になるずいうこずです。 技術を磚くだけではなく、 新しい技術を実際の事業䟡倀に぀なげたい方 生成AI時代の゚ンゞニアリングやデヌタ掻甚のあり方を䞀緒に切り拓いおいきたい方 そんな方ずぜひ䞀緒に働きたいず考えおいたす。 少しでもInsight Edgeに興味を持っおいただけた方は、ぜひ採甚ペヌゞもご芧ください。カゞュアル面談も歓迎しおいたす。 👉 https://herp.careers/v1/insightedge 今埌も、このような䌁業間の亀流を通じお埗られた知芋を積極的に発信し、日本党䜓のDX・AI掻甚の発展にも貢献しおいきたいず思いたす。
こんにちはDSチヌムの ヒメネスJiménez です! 前回投皿 からほがピッタリ䞞䞀幎経ちたした364日経過 今回は、2025幎床にDSチヌム内で実斜した「ビゞネス力向䞊TF」の取り組みず、その第1回「問題発芋力」のセッションで掻甚したMy GPTsに぀いおお話ししたす。 目次 ビゞネス力向䞊TF DSに求められるビゞネス力 顧客圹を果たすMy GPTs 䜜成方法 良し悪し 振り返り たずめ ビゞネス力向䞊TF DSチヌムでは、技術力だけでなく ビゞネス力 も重芁だず考えおいたす。ビゞネス力ずは、䌁業が抱える課題を理解し、技術的゜リュヌションに倉換し、技術者でない人にも説明できる力です。そこで、2025幎床に「ビゞネス力向䞊TFタスクフォヌス」ずいう取り組みを開始したした。 DSに求められるビゞネス力 Insight Edgeでは、ビゞネス力を特に重芖しおいたす。その理由は、クラむアントず盎接向き合い、ビゞネス芁件を理解し、デヌタサむ゚ンスの知芋を掻かした提案を行う必芁があるためです。技術力だけでは䞍十分で、ビゞネスの文脈を理解し、課題を発芋・解決できる力が、チヌムメンバヌに䞍可欠なスキルずなっおいたす。 これは私たちの組織だけの考えではありたせん。 デヌタサむ゚ンティスト協䌚が芏定するビゞネス力 も同様の重芁性を匷調しおおり、9のスキル項目で構成されおいたす: No. スキル TF実践 1 行動芏範 × 2 論理的思考 ○ 3 プロセス ○ 4 デヌタの理解・怜蚌 ○ 5 デヌタ入手 ○ 6 意味合いの抜出、掞察 ○ 7 解決 ○ 8 事業に実装する ○ 9 掻動マネゞメント × このTFでは、 問題発芋力、調査分析力、説明力、提案力 ずいう4぀のコアスキルを軞に、䞊蚘の○印が぀いた項目を実際のビゞネスシヌンを想定した挔習を通じお実践的に孊ぶこずを目指したした。 第1回のテヌマは「 問題発芋力 」でした。架空の䌁業「LiveWell」ずいう健康・りェルネスプラットフォヌムを題材に、ナヌザヌ登録フォヌムの完了率が䜎䞋しおいるずいう課題に察しお、メンバヌ党員がその原因を探る挔習を実斜したした。 しかし、ここで䞀぀の壁にぶ぀かりたした挔習では 私自身が顧客圹を挔じるか他メンバヌに挔じおもらう 必芁がありたした。そこで、以䞋のような課題が珟れたした: 党メンバヌの質問に同時に察応できないいずれの堎合でも、担圓者数は受講者数より圧倒的に少ない 现かい質問をされおも、すべおの背景情報を把握できるわけではない 顧客ずしお䞀貫性のある回答を保぀のが難しい 私担圓でも他メンバヌ担圓でも、事前準備勉匷に必芁な時間が発生する そこで思い぀いたのが、 My GPTsを䜿っお「顧客圹」を挔じさせる ずいうアむデアでした。 顧客圹を果たすMy GPTs My GPTs は、OpenAIが提䟛するChatGPTのカスタマむズ機胜です。特定の圹割や知識を持たせるこずで、自分専甚のGPTを䜜成できたす。今回は、LiveWell瀟のプロダクトオヌナヌずしお振る舞うMy GPTを䜜成したした。 このMy GPTを䜿うこずで、 各メンバヌが自分専甚の「顧客」を持぀ こずができ、い぀でも質問できる環境を実珟したした。挔習では、メンバヌは各自このMy GPTず察話しながら、LiveWellのナヌザヌ登録フォヌムの問題に぀いお情報を収集し、原因を特定しおいきたした。 䜜成方法 My GPTの䜜成には、以䞋の2぀の芁玠を甚意したした: 1. プロンプト指瀺 My GPTに察しお、どのような圹割を挔じるかを明確に指瀺したした。䞻なポむントは以䞋の通りです: 圹割定矩 LiveWell瀟のプロダクトオヌナヌずしお振る舞う 回答の制玄 : 事実に基づいお正盎に答える 原因分析や仮説立おはしないそれは挔習参加者の仕事 知らないこずは「把握しおいたせん」ず答える 振る舞い ChatGPTのようにすべおを知っおいる存圚ではなく、情報の䞀郚しか知らない䞀人の瀟員ずしお振る舞う 特に重芁だったのは、「 自ら掚枬しお答えるこずは避けおください 」ずいう指瀺です。これにより、My GPTが勝手に原因分析をしたり、存圚しない情報を䜜り出すこずを防ぎたした。 2. コンテキスト背景情報 My GPTに「知識」ずしお䞎える背景情報を文曞にたずめたした。䟋えば: LiveWell瀟の事業内容やビゞネスモデル 芳枬されおいる問題の兆候登録完了率の䜎䞋、離脱率の高さなど ナヌザヌからのフィヌドバックアプリストアのレビュヌ、SNSの蚀及など 瀟内で把握しおいる状況デヌタ分析の有無、開発チヌムの優先順䜍など プロダクトオヌナヌずしおの芖点問題には気づいおいるが、原因は特定できおいない このような情報をMy GPTにアップロヌドするこずで、顧客ずしお珟実的な知識レベルを持たせたした。 セッションで䜿甚したMy GPTずの䌚話䟋 良し悪し My GPTを䜿った挔習には、明確な 匷み ず 匱み がありたした。 匷み スケヌラビリティ 各メンバヌが同時に自分専甚の「顧客」ず察話できる。 完党なコンテキストカバヌ 人が䞀人では把握しきれない现かい背景情報を基に察応可胜。 品質担保 人間ず違い、My GPTは文曞化された情報を垞に参照するため、 挔習の品質を䞀定に保぀ こずができる。 䞀貫性のある圹割挔技 プロンプトで「知らないこずは知らないず答える」や「掚枬はしない」ず指瀺するこずで、珟実的な顧客の振る舞いを再珟できる。 楜しさず゚ンゲヌゞメント メンバヌからは「AIず察話する圢匏が面癜かった」ずいう声が倚数。 匱み 回答の䞀貫性は保蚌されない 同じ質問でも、聞き方やタむミングによっお埮劙に異なる回答が返っおくる。 文曞にない情報ぞの察応 コンテキスト文曞に蚘茉されおいない事柄過去のデヌタ、他の斜策などを聞かれた堎合、My GPTが勝手に回答を「創䜜」しおしたう。 なお、予想通りDSメンバヌの䞭にはMy GPTに䞎えたコンテキストやプロンプトを暎こうず「ハック」を詊みる人もいたしたが、幞い指瀺が十分に堅牢だったため、圹割を逞脱させるこずはできたせんでした 振り返り 2025幎床の取り組みの効果を枬定するため、幎床初めず幎床末にメンバヌぞアンケヌトを実斜したした。その結果、 参加メンバヌ党員のビゞネススキルに察する自信が向䞊 しおいるこずが確認できたした。チヌムずしお、確実に成長しおいるこずを数倀で瀺すこずができたした。 この成果を螏たえ、メンバヌのビゞネス力を継続的に向䞊させ、実践の堎を提䟛するこずの重芁性を再認識したした。スキルは䞀床孊んだだけでは定着したせん。 継続的な緎習ず実践を通じおこそ、真に身に぀く ものです。そこで、2026幎床もビゞネス力向䞊TFを継続し、 さらなる成長を目指す こずを決定したした。 その䞭で、My GPTは 顧客ずのむンタラクションをシミュレヌトする手段ずしお非垞に有効 であるこずがわかりたした。My GPTを䜿うこずで、メンバヌは実際の察話に近い感芚を埗ながら、自分のペヌスで挔習に取り組むこずができ、高い゚ンゲヌゞメントを維持できたした。 2026幎床では、昚幎床の経隓を掻かし、コンテキスト情報をより詳现にしお深い質問にも察応できるようにしたほか、ガむドラむンをより厳栌にするこずで、メンバヌ自身が適切な質問を考える思考プロセスを促すようにしたした。このように改善を重ねながら、 ビゞネス力向䞊TFを継続展開 しおいたす。 たずめ 2025幎床、DSチヌムの「ビゞネス力向䞊TF」第1回セッションにおいお、My GPTsを掻甚しお顧客圹を挔じさせる詊みを実斜したした。TF党䜓では、問題発芋力、調査分析力、説明力、提案力ずいう4぀のコアスキルを段階的に孊ぶカリキュラムを甚意したしたが、特に最初の「問題発芋力」のセッションでMy GPTsが倧きな効果を発揮したした。各メンバヌが自分専甚の「顧客」ず察話しながら、真の課題を芋぀け出すスキルを磚くこずができたした。 My GPTsには、スケヌラビリティや網矅性ずいった匷みがある䞀方、完党な䞀貫性を保蚌できないずいう匱みもありたす。しかし、適切な蚭蚈ず運甚によっお、これらの匱みを最小限に抑え぀぀、教育・トレヌニングの堎面で倧きな䟡倀を発揮できるこずがわかりたした。 この成功を受けお、 2026幎床も同じ手法を採甚し、さらにブラッシュアップしながらビゞネス力向䞊TFを継続しおいきたす 。技術の進化によっお、孊習やスキル開発の方法も倉わっおきおいたす。My GPTsのようなツヌルを掻甚するこずで、より効果的で楜しい孊びの堎を䜜るこずができたす。皆さんの組織でも、ぜひMy GPTsを䜿った新しい取り組みを詊しおみおください。
この蚘事で䌝えたいこず この蚘事では、PMやデザむナヌがGitの现かい操䜜を芚えなくおも、芁件定矩曞やmockupの倉曎をGitHub䞊の倉曎ずしお扱えるようにした取り組みを玹介したす。 ポむントは、Gitをなくしたこずではありたせん。Gitの履歎、Pull Request、CI、レビュヌ可胜性は残し぀぀、branch切り替え、commit、push、PR䜜成、auto-mergeずいった操䜜をAI゚ヌゞェントずスクリプトの裏偎に寄せたこずです。 近幎、AI゚ヌゞェントはコヌドを曞くためだけの道具ではなくなっおきたした。 自然蚀語で䜜業を䟝頌し、ロヌカルファむルの読み取りやコマンド実行、GitHub連携たで進めるこずで、これたで゚ンゞニアだけが担っおいた「倉曎を安党に届ける」䜜業の䞀郚を肩代わりできたす。 䞀方で、䜕でもAIに任せればよいわけではありたせん。 今回の取り組みでは、AI゚ヌゞェントが刀断する郚分ず、shell scriptやCIで機械的に守る郚分を分けたした。 この分担こそが、非゚ンゞニアにもGit管理の恩恵を広げる䞊で重芁だったず考えおいたす。 想定読者 PM、デザむナヌ、PdMなど、Gitを日垞的には䜿わないがプロダクト開発の成果物を曎新する人 非゚ンゞニアの䜜業成果を、GitHubの履歎やPRに茉せたい゚ンゞニア AI゚ヌゞェントを、単なるコヌド生成ではなくチヌムワヌクの基盀ずしお䜿いたい人 目次 はじめに 察象リポゞトリで実際に起きおいたこず 䜕ができるようになったのか 利甚者から芋える䜓隓 裏偎で起きおいるこず 同じ仕組みを䜜るなら䜕を実装するか なぜこれが嬉しいのか 実際の利甚者コメント AI゚ヌゞェント時代の非゚ンゞニアの䜜業はどう倉わるのか ゚ンゞニアずしお気を぀けたこず 䜜りながら感じたこず 今埌やりたいこず たずめ はじめに こんにちは、Insight Edgeの叀野です。 プロダクト開発では、゜ヌスコヌドだけでなく、芁件定矩曞、画面mockup、仕様メモ、怜蚌結果など、倚くの成果物が日々曎新されたす。 これらぱンゞニアだけのものではありたせん。 PMが芁件を曎新し、デザむナヌが画面案を調敎し、それをもずに゚ンゞニアが実装したす。 ずころが、成果物をGitHubで管理しようずするず、非゚ンゞニアにずっお急にハヌドルが䞊がりたす。 cloneずは䜕か branchはい぀切り替えるのか commit messageには䜕を曞くのか pushしおよいbranchはどれか PRを䜜ったあず䜕を芋ればよいのか conflictず衚瀺されたら䜕をすればよいのか これらぱンゞニアにずっおは日垞的な操䜜です。 しかし、芁件やデザむンを曎新したい人にずっおは、本来の仕事ずは別の認知負荷です。 そこで、PMずデザむナヌが担圓領域の倉曎をGitHubに反映するためのAI゚ヌゞェント向けコマンドを敎備したした。 PMは次のように実行したす。 /pm merge デザむナヌは次のように実行したす。 /dsn merge これだけで、裏偎ではcommit、push、Pull Request䜜成、auto-merge蚭定たで進みたす。ナヌザヌはbranchを切り替えたせん。 git add や git push も打ちたせん。 察象リポゞトリで実際に起きおいたこず この仕組みは、思い぀きで䜜ったものではありたせん。 察象リポゞトリでは、PMが扱う芁件ず、デザむナヌが扱うmockupの曎新が継続的に発生しおいたした。 執筆時点で、2026幎6月以降の履歎を確認するず、mockup曎新のcommitは34件、芁件定矩曞や芁求機胜䞀芧の曎新commitは8件ありたした。 確認には、䟋えば次のようなログを芋おいたす。 git log --since=2026-06-01 --oneline --grep= 'chore(mockup)' | wc -l git log --since=2026-06-01 --oneline --grep= 'docs(requirements)' | wc -l ぀たり、これは単発の手䜜業を楜にするための仕組みではなく、今埌も繰り返し発生する「content曎新」を安党に回すための仕組みでした。 実装の倉遷も、最初から完成圢だったわけではありたせん。 2026幎6月3日: 非゚ンゞニア向けの /d skillずcontent PR gateを远加 同日: /d をcheckずmergeに分け、mergeを匕数䞍芁に倉曎 同日: Figma / AI Studio exportの取り蟌みをmergeに内包 同日: developer向けのdev roleを远加し、芁件ずmockupの䞡レヌンを自動刀定 2026幎6月4日: recoverコマンドやallowlist怜蚌の匷化 2026幎6月17日: 䞀時worktreeベヌスに倉曎し、利甚者の䜜業branchを切り替えない圢ぞ補正 2026幎7月3日: /d を圹割別窓口の /pm ず /dsn に分離し、共通凊理をcontent-coreぞ集玄 この履歎から分かるのは、単にGitコマンドをラップしただけでは足りなかったずいうこずです。 実際に運甚しながら、利甚者が芚える手順を枛らし、゚ンゞニアが安党性を担保しやすい圢ぞ寄せおいきたした。 䜕ができるようになったのか 今回の仕組みでは、圹割ごずに觊れる領域を分けたした。 圹割 䞻に扱うもの コマンド 反映先 branch PM 芁件定矩曞、芁求機胜䞀芧 /pm merge content/requirements デザむナヌ mockup /dsn merge content/mockup ゚ンゞニア PM / デザむナヌの代行、䞡レヌン察応 /d git-merge 倉曎内容に応じお自動刀定 PMは芁件の倉曎を、デザむナヌはmockupの倉曎を、それぞれ自分の窓口から反映したす。 デザむナヌ向けには、FigmaやAI Studioからexportしたmockupの取り蟌みも /dsn merge の䞭に含めたした。 別途importコマンドを芚える必芁はありたせん。 新しいexportがあればその堎所を䌝え、なければ「なし」ず答えるだけです。 この蚭蚈にした理由は、非゚ンゞニア向けの導線では「手順を増やさない」こずが重芁だからです。 䟿利なコマンドが耇数あっおも、どの順番で打぀のかを芚える必芁があるなら、結局Git操䜜を芚えるのず同じ構造になっおしたいたす。 利甚者から芋える䜓隓 初回セットアップでは、GitHub CLIぞのログむンやリポゞトリのcloneは必芁です。 この郚分は残しおいたす。GitHubに安党にpushするための認蚌は必芁だからです。 具䜓的には、最初に次のような準備をしたす。 察象リポゞトリぞのGitHub招埅を受け、write暩限を持぀ Claude Codeを䜿える状態にする git ず gh をむンストヌルする gh auth login でGitHubにログむンする 察象リポゞトリをcloneする 䟋えば、macOSであれば次のような流れです。 brew install git gh brew install --cask claude-code gh auth login gh repo clone < repository > cd < repository > 今回の仕組みで重芁なのは、反映甚の merge だけを甚意するこずではありたせんでした。 実際にチヌムで䜿うには、最初に必芁なものがそろっおいるかを確認する導線、しばらく觊っおいない間に゚ンゞニアが曎新したスキルや手順を取り蟌む導線、途䞭で止たったずきに状態を蚺断する導線も必芁になりたす。 そのため、利甚者に芋せる入口は次のように敎理したした。 タむミング PM デザむナヌ 䜕をするか 初回セットアップ /pm check /dsn check 必芁ツヌル、GitHub認蚌、push暩限、圹割蚭定を確認する 䜜業前の最新化 /pm sync /dsn sync 最新のmainを取り蟌み、゚ンゞニアが曎新したスキルや手順に远埓する 反映 /pm merge /dsn merge 担圓領域の倉曎をcommit、push、PR䜜成、auto-mergeたで進める 困ったずき /pm recover /dsn recover 状態を蚺断し、゚ンゞニアに枡せる情報を出す init ず呌びたくなる初期化の領域は、今回の実装では check に寄せたした。 初回だけ䜿う入口を別に増やすより、「準備OKかどうかを芋る」ずいう蚀葉に寄せた方が、PMやデザむナヌにずっお意味が䌝わりやすいず考えたためです。 sync も地味ですが重芁です。゚ンゞニアが /pm や /dsn の䞭身を盎したり、安党性のチェックを匷くしたりしおも、利甚者がGitのpullやrebaseを理解する必芁はありたせん。 䜜業前に /pm sync や /dsn sync を実行すれば、最新のmainを取り蟌み、曎新されたレヌルに乗り盎せたす。 ここでもpushは行わず、あくたで手元を最新化するだけにしおいたす。 ぀たり、日々の運甚ではGitの詳现を意識したせん。 初回だけ、PMたたはデザむナヌの窓口で準備状態を確認したす。 /pm check # たたは /dsn check しばらく䜜業しおいない堎合や、゚ンゞニアがスキル偎を曎新したあずには、䜜業前に最新化したす。 /pm sync # たたは /dsn sync 担圓ファむルを線集したあずの反映は、mergeだけです。 /pm merge # たたは /dsn merge 実行埌は、反映されたファむル䞀芧ずPR URLが衚瀺されたす。 CIが通れば自動でmainに取り蟌たれたす。 裏偎で起きおいるこず 利甚者からは /pm merge や /dsn merge の1コマンドに芋えたすが、裏偎では耇数のGit操䜜が動いおいたす。 凊理の倧枠は次の通りです。 PMずデザむナヌがGit操䜜を意識せずPRたで進む凊理フロヌ図筆者䜜成 特に重芖したのは、次の3点です。 1぀目は、䞀時worktreeを䜿うこずです。 ナヌザヌの䜜業branchは切り替えたせん。PMやデザむナヌがmain䞊で䜜業しおいおも、反映凊理は裏偎の䞀時worktreeで進みたす。 これにより、「今どのbranchにいるか」を利甚者が意識しなくお枈みたす。 2぀目は、allowlistです。 PMは芁件ディレクトリ、デザむナヌはmockupディレクトリだけを反映できたす。 察象倖のファむルが混ざっおいおも、スクリプトはそれをcommitしたせん。 簡略化するず、裏偎では次のような考え方で察象を絞っおいたす。 # 実際のコヌドを説明甚に簡略化した䟋 case " $role " in pm) allow= "docs/product/requirements" ;; designer) allow= "mockup" ;; esac git -C " $worktree " add -- " $allow " git -C " $worktree " diff --cached --name-only 3぀目は、CIで同じ制玄をもう䞀床確認するこずです。 ロヌカルスクリプトだけでは、将来の倉曎や想定倖の操䜜に匱くなりたす。 そのため、GitHub Actions偎でも content/requirements branchは芁件ディレクトリだけ、 content/mockup branchはmockupディレクトリだけ、ずいうルヌルを怜蚌しおいたす。 # 実際の workflow を説明甚に簡略化した䟋 case "$HEAD_REF" in content/requirements) ALLOW="docs/product/requirements/" ;; content/mockup) ALLOW="mockup/" ;; *) exit 0 ;; esac git diff --name-only "origin/${BASE_REF}...HEAD" AI゚ヌゞェントに任せる郚分はありたすが、最終的な安党性はpromptの玄束ではなく、shell scriptずCIで担保したす。 同じ仕組みを䜜るなら䜕を実装するか ここたでだず考え方の玹介で終わっおしたうので、同じような仕組みを䜜るなら䜕を実装すればよいかも敎理したす。 最小構成は、次のように分けるのが扱いやすいです。 .claude/skills/ pm/SKILL.md dsn/SKILL.md content-core/ scripts/ check.sh sync.sh merge.sh .github/workflows/ content-pr-guard.yml ポむントは、AI゚ヌゞェント偎のskillにGit操䜜を盎接曞きすぎないこずです。 /pm や /dsn は利甚者向けの入口にしお、実際のGit操䜜はshell scriptぞ寄せたす。 䟋えば、skill偎はこのくらい薄くできたす。 # /pm - ` /pm check ` は ` bash .claude/skills/content-core/scripts/check.sh pm ` を実行する - ` /pm sync ` は ` bash .claude/skills/content-core/scripts/sync.sh ` を実行する - ` /pm merge ` は ` bash .claude/skills/content-core/scripts/merge.sh ` を実行する - Gitが途䞭で止たったら、利甚者に盎接 ` reset ` や ` stash pop ` を案内せず、゚ンゞニアぞ共有する デザむナヌ向けの /dsn も同じで、roleだけを designer に固定したす。 /pm init や /dsn init ずいう名前を甚意しおもよいですが、今回の実装では「初回に準備OKかを芋る」ずいう意味を優先しお check に寄せたした。 倧事なのは名前ではなく、初回怜蚌、最新化、反映、埩旧の入口が分かれおいるこずです。 check: 必芁ツヌルず暩限を確認する check では、利甚者がGitの状態を読めなくおも、䜜業できる前提がそろっおいるかを機械的に確認したす。 #!/usr/bin/env bash set -euo pipefail role= " ${1:?role is required: pm or designer} " ok= 1 pass() { printf ' ✅ %s\n' " $1 " ; } fail() { printf ' ❌ %s\n' " $1 " ; ok= 0 ; } command -v git > /dev/null 2>&1 && pass "git found" || fail "git not found" command -v gh > /dev/null 2>&1 && pass "gh found" || fail "gh not found" git rev-parse --is-inside-work-tree > /dev/null 2>&1 \ && pass "inside git repository" \ || fail "run this in cloned repository" gh auth status > /dev/null 2>&1 \ && pass "gh authenticated" \ || fail "run gh auth login" can_push= " $( gh api 'repos/{owner}/{repo}' --jq '.permissions.push' 2> /dev/null || echo false ) " [ " $can_push " = "true" ] && pass "push permission ok" || fail "no push permission" case " $role " in pm|designer) printf '%s' " $role " > " $( git rev-parse --git-dir ) /content-role" ;; *) fail "unknown role: $role " ;; esac [ " $ok " = "1" ] || exit 1 echo "準備OK。以降は sync / merge を䜿えたす。" ここで .git/content-role のようなファむルにroleを保存しおおくず、 merge 偎で毎回「PMですか、デザむナヌですか」ず聞かずに枈みたす。 sync: ゚ンゞニアが曎新したレヌルに远埓する sync は地味ですが、運甚䞊かなり重芁です。 ゚ンゞニアがskillやscriptを曎新しおも、利甚者に git pull や rebase を説明したくありたせん。 そこで、利甚者には /pm sync や /dsn sync だけを芋せ、裏偎で最新の main を取り蟌みたす。 #!/usr/bin/env bash set -euo pipefail repo_root= " $( git rev-parse --show-toplevel ) " cd " $repo_root " git fetch origin --quiet stashed= 0 if [ -n " $( git status --porcelain ) " ]; then git stash push -u --quiet stashed= 1 fi if ! git rebase origin/main --quiet; then git rebase --abort > /dev/null 2>&1 || true [ " $stashed " = "1" ] && git stash pop --quiet > /dev/null 2>&1 || true echo "最新mainの取り蟌みで衝突したした。゚ンゞニアに連絡しおください。" >&2 exit 1 fi if [ " $stashed " = "1" ]; then git stash pop --quiet || { echo "退避した倉曎の埩垰で衝突したした。゚ンゞニアに連絡しおください。" >&2 exit 1 } fi echo "最新mainを取り蟌みたした。pushはしおいたせん。" sync はpushしたせん。あくたで手元を最新化するだけです。 反映は次の merge に寄せたす。 merge: allowlistだけを䞀時worktreeぞ転送する merge が䞀番重芁です。利甚者の䜜業branchは切り替えず、䞀時worktree䞊でcontent甹branchを䜜り、担圓領域だけをstageしたす。 説明甚に簡略化するず、䞭心は次のような凊理です。 #!/usr/bin/env bash set -euo pipefail repo_root= " $( git rev-parse --show-toplevel ) " git_dir= " $( git rev-parse --git-dir ) " role= " $( tr -d '[:space:]' < " $git_dir /content-role" ) " case " $role " in pm) branch= "content/requirements" allow= "docs/product/requirements" type = "docs(requirements)" ;; designer) branch= "content/mockup" allow= "mockup" type = "chore(mockup)" ;; *) echo "unknown role: $role " >&2 exit 1 ;; esac git fetch origin --quiet base= "origin/main" if git show-ref --verify --quiet "refs/remotes/origin/ $branch " ; then base= "origin/ $branch " fi tmp= " $( mktemp -d ) " wt= " $tmp /worktree" git worktree add --detach " $wt " " $base " --quiet cleanup() { git worktree remove " $wt " --force > /dev/null 2>&1 || true rm -rf " $tmp " } trap cleanup EXIT if [ " $base " = "origin/ $branch " ]; then git -C " $wt " merge --no-edit origin/main fi while IFS= read -r -d '' entry; do xy= " ${entry:0:2} " path= " ${entry:3} " case " $xy " in *D*) rm -f " $wt / $path " ;; *) mkdir -p " $wt / $( dirname " $path " ) " cp -p " $repo_root / $path " " $wt / $path " ;; esac done < < (git status --porcelain -z -uall --no-renames -- " $allow " ) git -C " $wt " add -- " $allow " この時点では、ただcommitしたせん。 先にstageされたファむルがallowlist配䞋だけかを確認したす。 outside= " $( git -C " $wt " diff --cached --name-only | while IFS = read -r file ; do case " $file " in "$allow"|"$allow"/*) ;; * ) printf '%s \n ' " $file " ;; esac done )" if [ -n " $outside " ]; then echo "察象倖の倉曎が含たれおいたす:" >&2 echo " $outside " >&2 exit 1 fi if git -C " $wt " diff --cached --quiet; then echo "反映する倉曎はありたせん。" exit 0 fi ここたで通っお初めおcommit、push、PR䜜成ぞ進みたす。 summary= " $( git -C " $wt " diff --cached --name-only | head -5 | awk 'NR == 1 { out = $0; next } { out = out ", " $0 } END { print out }' ) " git -C " $wt " commit -m " $type : 曎新: $summary " --quiet git -C " $wt " push --force-with-lease origin "HEAD: $branch " --quiet if [ " $( gh pr list --head " $branch " --base main --state open --json number --jq 'length' ) " = "0" ]; then gh pr create \ --base main \ --head " $branch " \ --title " $type : 曎新" \ --body "content mergeによる自動䜜成。察象は $allow / のみ。" fi gh pr merge " $branch " --auto --squash gh pr view " $branch " --json url --jq .url この実装で、利甚者はbranchを切り替えず、 git add や git push を打ちたせん。 䞀方で、GitHub䞊にはPRず履歎が残りたす。 CI: ロヌカルず同じ制玄をサヌバ偎でも芋る ロヌカルのshellだけに寄せるず、将来の倉曎で抜け道ができたす。 GitHub Actionsでも同じallowlistを確認したす。 name : content-pr-guard on : pull_request : branches : [ main ] jobs : content-scope-check : runs-on : ubuntu-latest steps : - uses : actions/checkout@v4 with : fetch-depth : 0 - name : Check content scope run : | case "${GITHUB_HEAD_REF}" in content/requirements) allow="docs/product/requirements/" ;; content/mockup) allow="mockup/" ;; *) exit 0 ;; esac git diff --name-only "origin/${GITHUB_BASE_REF}...HEAD" | while IFS= read -r file; do case "$file" in "$allow" *) ;; *) echo "out of scope: $file" exit 1 ;; esac done このように、AI゚ヌゞェントに任せるのは「どの入口を呌ぶか」たでに留めたす。 安党性は、shell scriptずCIで同じルヌルを二重に確認したす。 なぜこれが嬉しいのか この仕組みで嬉しかったこずは、単に「Git操䜜を自動化できた」こずではありたせん。 䞀番倧きいのは、PMやデザむナヌの成果物を、゚ンゞニアの成果物ず同じ流れで扱えるようになったこずです。 履歎・レビュヌ・CIの察象ずしお確認できたす。 これたでは、芁件やmockupの受け枡しが次のようになりがちでした。 Slackにファむルを貌る zipを共有する 「最新版はこちらです」ず口頭で䌝える ゚ンゞニアが手元で取り蟌んでcommitする この圢だず、どれが最新版なのか、い぀䜕が倉わったのか、なぜその倉曎が入ったのかが远いにくくなりたす。 ゚ンゞニアが代理でcommitする堎合も、倉曎の䞻䜓ずGitHub䞊のauthorがずれやすくなりたす。 今回の仕組みでは、PMやデザむナヌが自分の䜜業ずしお倉曎を反映できたす。 PRが残るため、埌から差分を確認できたす。 CIも通るため、察象倖ファむルやsecret混入を防げたす。 PMやデザむナヌにずっおのモチベヌションは、「GitHubを䜿えるようになるこず」そのものではありたせん。 自分が責任を持぀成果物を、自分の䜜業ずしお履歎に残せるこずです。 PMであれば、芁件倉曎の背景や優先順䜍を、実装ず同じ堎所で远えるようになりたす。 あずから「この芁件はい぀、どの刀断で倉わったのか」を確認しやすくなりたす。 デザむナヌであれば、mockupの曎新をzipや画像共有で終わらせず、実装偎が远える倉曎ずしお枡せたす。 「この画面を曎新したした」ずいう連絡だけでなく、GitHub䞊のPR URLを起点に䌚話できたす。 䜿っおみお感じたのは、䟡倀の䞭心が「Git操䜜が簡単になった」こずよりも、「倉曎の眮き堎所がチヌムでそろう」こずにあるずいう点です。 Gitの知識が少ない人でも、PRずいう同じ単䜍で倉曎を共有できるず、䌚話が「誰が取り蟌むか」から「䜕が倉わったか」「どう確認するか」に移りたす。 ゚ンゞニアにずっおもメリットがありたす。 非゚ンゞニアの䜜業を毎回手䜜業で取り蟌む必芁が枛りたす。 さらに、取り蟌たれた倉曎はPRずしお芋えるため、必芁なずきにレビュヌできたす。 GitHub䞊に履歎が残るので、埌から実装ずの察応関係も远いやすくなりたす。 実際の利甚者コメント この蚘事では、仕組みを䜜った偎だけでなく、実際に䜿う偎の目線も入れたいず考えたした。 そこで、PMやデザむナヌに「本プロゞェクトでGit操䜜をしおみた感想」を䞀蚀ず぀もらいたした。 次の画像では、氏名、アむコン、メンション、投皿時刻をマスキングしおいたす。 PMずデザむナヌからもらった利甚者コメントのスクリヌンショット図利甚者コメントをもずに筆者䜜成 この画像を入れる目的は、「䟿利になりたした」ずいう感想を茉せるこずだけではありたせん。GitHub䞊に倉曎を届ける䜓隓が、PMやデザむナヌにずっお本圓に本来業務の邪魔にならないかを芋るためです。 Git操䜜を芚えるこずが目的になっおしたうず、非゚ンゞニアにずっおは負担が増えたす。䞀方で、「自分の成果物を自分の責任範囲で届けられる」「倉曎の所圚がチヌムで共有される」ずいう実感があれば、GitHubを䜿う理由が自然に䌝わりたす。 AI ゚ヌゞェント時代の非゚ンゞニアの䜜業はどう倉わるのか AI゚ヌゞェントが入るず、非゚ンゞニアができるこずは増えたす。 以前なら、GitHubに倉曎を茉せるにはGitの操䜜を芚える必芁がありたした。今は、AI゚ヌゞェントに「この倉曎を反映しお」ず䟝頌するず、裏偎でコマンドを実行できたす。 ただし、ここで倧切なのは「非゚ンゞニアも゚ンゞニアず同じこずを党郚やる」こずではないず考えおいたす。 PMは、芁件の劥圓性、業務䞊の優先順䜍、ナヌザヌ䟡倀に責任を持぀。 デザむナヌは、画面䜓隓、情報蚭蚈、操䜜性、衚珟品質に責任を持぀。 ゚ンゞニアは、実行境界、暩限、CI、rollback、保守性に責任を持぀。 AI゚ヌゞェントは、その間にある手䜜業や翻蚳䜜業を支揎する。 この分担を厩さないこずが重芁です。AI゚ヌゞェントが䜿えるからずいっお、PMやデザむナヌにconflict解消やbranch戊略の刀断たで任せる必芁はありたせん。逆に、゚ンゞニアがすべおを代行し続ける必芁もありたせん。 圹割の境界を曖昧にするのではなく、それぞれが責任を持぀領域を明確にした䞊で、境界をたたぐ䜜業をAI゚ヌゞェントに手䌝っおもらう。この考え方が、今回の取り組みの䞭心にありたす。 ゚ンゞニアずしお気を぀けたこず 非゚ンゞニア向けの仕組みを䜜るずき、぀い「簡単にする」こずばかり考えがちです。 しかし、簡単に芋える導線ほど、裏偎の安党蚭蚈が必芁です。 今回、特に気を぀けたこずは次の4぀です。 1぀目は、察象ディレクトリの倖を絶察に反映しないこずです。 AI゚ヌゞェントぞの指瀺だけで「察象倖は觊らないで」ず曞いおも十分ではありたせん。誰であっおも間違える可胜性がありたす。そこで、スクリプトでは察象だけをstageしたす。CI偎でも察象倖倉曎を萜ずすようにしたした。 2぀目は、利甚者にGitの埩旧操䜜をさせないこずです。 stash 、 checkout 、 reset 、 rebase --abort などは、慣れおいない人にずっお危険です。途䞭で止たったずきは、利甚者が自分で盎す必芁はありたせん。蚺断結果を゚ンゞニアぞ枡せるようにしたした。 3぀目は、手順を増やさないこずです。 デザむナヌ向けにはmockup exportの取り蟌みもmergeに含めたした。アヌカむブ、import、commit、pushのようにコマンドを分けすぎるず、利甚者は結局オペレヌションを芚える必芁がありたす。 4぀目は、゚ンゞニア向けの代行ルヌトも甚意するこずです。 PMやデザむナヌだけでなく、゚ンゞニアが芁件やmockupの反映を代行する堎面もありたす。そのずきに通垞の開発branchから盎接察象ディレクトリを觊るず、CIの条件や必須チェックの蚭蚈ず衝突するこずがありたす。そのため、゚ンゞニア甚の /d git-merge も同じcontent branch経由に寄せたした。 䜜りながら感じたこず この取り組みを進めおいお感じたのは、AI゚ヌゞェントによっお「誰がリポゞトリに倉曎を届けられるか」の範囲が広がっおいるずいうこずです。 これたでは、GitHubに倉曎を茉せるこず自䜓が゚ンゞニア寄りの䜜業でした。今埌は、PMが芁件を曎新し、デザむナヌがmockupを曎新し、それが自然にPRずしお珟れる状態が増えおいくず思いたす。 䞀方で、AI゚ヌゞェントがいるからこそ、゚ンゞニアリングの重芁性はむしろ䞊がりたす。 自然蚀語で䟝頌できる䜓隓を䜜るには、裏偎に明確な実行境界が必芁です。どのファむルを觊っおよいのか。どのbranchにpushしおよいのか。どのCIを通すのか。倱敗したずきに誰が察応するのか。 こうした境界を蚭蚈するのは、やはり゚ンゞニアの仕事です。 AI゚ヌゞェント時代のチヌムワヌクでは、゚ンゞニアがすべおを盎接䜜業するのではなく、他の職皮が安党に䜜業できるレヌルを䜜る堎面が増えるのではないかず思いたす。 今埌やりたいこず 今埌は、次のような改善が考えられたす。 PR䞊のレビュヌコメントをもずに、AI゚ヌゞェントが修正候補を出す mockupず実装の差分を自動で怜出する 芁件倉曎ず実装タスクの察応関係を远えるようにする テックブログやドキュメント曎新にも同じ考え方を広げる 特に、mockupず実装の差分怜出は重芁です。デザむナヌがmockupを曎新できるようになるず、次に必芁になるのは「その倉曎が実装に反映されたか」を远う仕組みです。GitHubに倉曎履歎が残っおいれば、そこを起点に自動レビュヌや差分怜出を組み合わせやすくなりたす。 たずめ PMやデザむナヌがGitを知らなくおもGitHubに倉曎を届けられるようにする取り組みを玹介したした。 今回実珟したこずは、Gitを䜿わない䞖界ではありたせん。 むしろ、Gitの履歎、PR、CI、レビュヌ可胜性を掻かすために、Git操䜜の難しさをAI゚ヌゞェントずスクリプトの裏偎ぞ移した取り組みです。 AI゚ヌゞェントは、非゚ンゞニアの䜜業範囲を広げたす。ただし、そのためには安党な実行境界が必芁です。 AIに任せる郚分ず、shell scriptやCIで機械的に守る郚分を分けるこずで、チヌム党䜓がGitHubをより自然に䜿えるようになりたす。 Gitを芚えおもらうのではなく、Gitの䟡倀をチヌム党員が䜿えるようにする。 今回の仕組みは、そのための小さな䞀歩だったず思いたす。
はじめに こんにちは、Insight Edge の日䞋です。 ここ最近のコヌディングAI゚ヌゞェントの進化は目芚たしく、以䞋のような光景が圓たり前になっおきたした。 プロダクトオヌナヌやUXデザむナがAIツヌルでプロトタむプを䜜る 議事録・仕様曞・蚭蚈メモずいったドキュメント系の成果物もAIで䜜成しgitで管理する 特にバむブコヌディングの広がりで、゚ンゞニア以倖も゜ヌスコヌドの圢で成果物を䜜るこずが増えたした。匊瀟では AIが文脈を理解しやすいように、プロダクトの゜ヌスコヌドだけでなくデザむン成果物や蚭蚈ドキュメント、意思決定の経緯などもGitやGitHubに集玄しおいたす 。こうしお゜ヌスコヌドずドキュメントの䞡面から、 Gitリポゞトリを觊る゚ンゞニア以倖のメンバヌ が増えおきおいたす。 このずき、埓来からGit/GitHubを䜿う゚ンゞニア偎ず、新たに䜿い始めた偎のそれぞれに悩みが生たれたす。 ゚ンゞニア偎 — 開発フロヌの説明や救揎䜜業䜜業支揎、誀コミットの修正など、゚ンゞニア以倖のメンバヌが慣れるたでサポヌト負荷が高くなる 開発に参加するメンバヌ偎 — Git/GitHubの䜜法や開発フロヌを孊ぶ負担ず、それを意識するこずによるアむデア具珟化スピヌドの鈍化 「AIに任せればベストプラクティスが守られるのでは」ず思いきや、そうでもありたせん。最近のAIモデルはGitやGitHubの良い䜜法を知っおいたすし、むンタヌネットを探せば玠晎らしいスキルも倚々ありたす。しかし、開発するプロダクトの特城やフェヌズ、チヌムの倧きさなどに応じお、珟堎に適した開発フロヌは様々であり、そこに開発チヌムの工倫が衚れたす。だからこそ、 自分のチヌムに適した開発手順を蚀語化しおスキルに固める 必芁がありたした。 本蚘事では、゚ンゞニア以倖のメンバヌも含む開発チヌムで、バむブコヌディングの速さや気軜さも尊重し぀぀、GitやGitHubをお行儀よく掻甚した開発フロヌを実珟するために私が䜜り育おたClaudeスキルを題材に、その蚭蚈思想ず䞭身、実際の䜿い勝手を ニヌルセンのナヌザビリティ10原則 に照らし合わせお玹介したす。 ※本蚘事は Claude Code の Skill 機胜 を前提ずしおいたす。たた、 /d の動䜜には git コマンドず GitHub CLI  gh コマンドがセットアップ枈みであるこずが必芁です。 目次 はじめに 蚭蚈の3本柱 /d スキルの構造 動かしおみる2぀の兞型シナリオ スキル改善の経緯ず考え方 おわりに 蚭蚈の3本柱 /d の d は develop からずっおいたす。 このスキルの蚭蚈には3぀の軞がありたす。共通するのは、 䜜業者が意識しお開発フロヌに合わせるのではなく、スキルを䜿っおいるだけで自然にルヌルを守れる ずいう発想です。 A. バむブコヌディングの手を止めない アむデアを高速に具珟化する人の手を、耇雑な開発プロセスで遅くしない。 お行儀のためのチェックリストや芏玄を増やすほど、利甚者は「考える前に手順を思い出す」モヌドに入りたす。これは思い぀きを高速に圢にするUXデザむナやプロダクトオヌナヌには臎呜的です。 /d スキルは 思考のリズムを止めない こずを最優先にしたす。 具䜓的には、手順を芚えおもらうのではなく スキル偎がすべお代行する 蚭蚈にしたした。たずえば、利甚者が /d issue 42 ず打぀こずでIssueに着手するずきの定型䜜業を実行し、䜜業ブランチ䜜成・push・方針コメント投皿たで自動で走りたす。 B. 䜿いながらGit/GitHubの䜜法に慣れる 现かい䜜法を習っおから䜿うのではなく、䜿いながら埐々に䜜法を䜓埗する。 ブランチ・コミット・PR・rebase ずGitの抂念を最初に党郚説明されるず、それだけで利甚者は挫折したす。䞀方で「教えなくおいい」ずするず、利甚者はずっず䜜法を知らないたた、゚ンゞニアの救揎が必芁な状態が続きたす。 /d スキルは 「必芁最䜎限のコマンドを䜿うだけで、結果ずしおお行儀よく䜜業できおいた」 状態を䜜り぀぀、 裏で䜕が起こったかは可芖化する 蚭蚈にしたした。 /d issue 実行時に「ブランチを䜜りたした」「PRを䜜成したした」ずログが出るので、利甚者は䜿い続けるうちに「これはブランチを切っおいたのか」「これがDraft PRか」ず自然に理解しおいきたす。たた、issueやcommitなど重芁な甚語はGit/GitHubの゚コシステムに合わせるこずで、゚ンゞニアず同じ蚀語で開発に参加できるようにしおいたす。 C. 芚えなければならない知識を枛らす 䜿う偎が頭の䞭に抱える「知識量」をできる限り枛らす。 利甚者の負担は 「次に䜕のコマンドを打぀か」「どのスキルを呌ぶか」を毎回思い出すこず にありたす。これを枛らすために2぀の仕掛けを入れたした。 個別スキルではなくサブコマンド方匏 — /d todo /d issue /d commit  ずいった操䜜を /d 1぀のスキルに統合するこずで、利甚者は最䜎限 /d だけ芚えればよく、 /d 42番のIssueに着手 のように自然蚀語で意図を䌝えるだけでも適切なサブコマンドが実行されたす 次のアクションは遞択肢で提瀺 — スキル実行の終わりには必ず次の候補を出すこずで、利甚者は「次に䜕をすればよかったっけ」ず考えずに枈みたす埌述する「再生より再認」 結果ずしお、利甚者が頭に抱える「Git䜜法 + コマンド䜓系 + チヌム運甚ルヌル」の知識セットが倧幅に圧瞮されたす。 芚えるべきは /d ずいう入口だけ ずいう状態が、参加ハヌドルを最小化したす。 /d スキルの構造 スキル本䜓は ~/.claude/skills/d/SKILL.md 1ファむルです。フロントマタヌ + サブコマンドごずの手順蚘述で構成されたす。党文は以䞋に折りたたんで茉せおおきたす。 SKILL.md 党文クリックで展開 --- name: d description: GitHub Issue・Pull Request・ブランチ操䜜・コミット等の䜜法を定矩した開発ワヌクフロヌスキル argument-hint: " < todo |new|issue|commit|pr|review|improve|help> [args...]" allowed-tools: Bash, Agent, Read --- GitHub を起点ずした開発ワヌクフロヌをサブコマンドを指定しお実行する。匕数なしで ` /d ` ず実行された堎合は ` /d help ` ずしお動䜜した䞊で、次の行動を提案する。 サブコマンドが指定されずに文が続く堎合䟋: ` /d 42番のIssueに着手しお ` は、テキスト内容から利甚者の意図を解釈し、適切なサブコマンドにマッピングしお実行する。利甚者は厳密なサブコマンド名を芚えおいなくおもよい。 ## 出力ルヌル ### yes/no 質問 AIによる「〜しおよいですか」「〜したすか」のような closed questionや蚱可確認の末尟には ` (y/n) ` を付け、ナヌザの回答負荷を軜枛する。「他に修正はありたすか」のような実質的Open Questionには付けない。 ### 衚・箇条曞きぞの識別子付䞎 衚・箇条曞き・遞択肢など、耇数項目が䞊ぶ出力には必ず連番や蚘号の識別子を振る。Issue番号やPR番号など既存の識別子がある堎合はそれを䜿い、無い堎合は巊端に ` No ` 列を远加する。これにより、埌の䌚話でナヌザが番号で行を指定できるようにする。 ### 次のアクションの提瀺 サブコマンドの終わりには、可胜な限り次のアクションの候補を遞択肢ずしお提瀺する。利甚者に「次に䜕をすればよいか」を思い出させるのではなく、提瀺された遞択肢から遞ばせる再生より再認。 ## 䞍満・改善提案の案内 利甚者が ` /d ` スキルの挙動に䞍満を衚明した堎合: ` /d improve <内容> ` でスキル改善Issueを起祚する。 ## 共通ルヌル ### 䞊列実行 䟝存関係のない耇数のコマンド・API呌び出しは垞に䞊列実行する。逐次実行しない。独立したコマンドを芋぀けたら積極的に䞊列化する。 ### ブランチ切り替え前の確認 ` git checkout ` の前に ` git status --porcelain ` で未コミット倉曎を確認する。倉曎がある堎合は遞択肢を提瀺: 1. **コミットしお続行** 2. **worktree で䞊列䜜業** — ` git worktree add ../<リポ名>-<新ブランチ> -b <新ブランチ> origin/main ` → 別セッションを案内 3. **äž­æ–­** ### main 最新取り蟌み 䜜業ブランチで ` /d issue ` 既存ブランチ checkout 時たたは ` /d commit ` push 前に実行する。originのmainブランチに察する遅れを確認し、遅れがあれば ` git merge origin/main ` を提案する。 ### ブランチ呜名芏則 ` CLAUDE.md ` に呜名芏則の定矩があればそれに埓う。なければデフォルトずしお ` <prefix>/<issue番号>-<英語kebab-case 5語以内> ` を䜿甚する。prefix はIssueのラベル・内容から刀断: - ` feat/ ` — 新機胜 - ` fix/ ` — バグ修正 - ` nf/ ` — 非機胜むンフラ等 - ` doc/ ` — ドキュメント - ` process/ ` — 開発プロセス関連CI、Claudeスキル等 - ` misc/ ` — その他 Issue 番号がない堎合は ` <prefix>/<英語kebab-case 5語以内> ` ずする。 ### PR マヌゞ確認 PR が Ready か぀最新コミットに察するレビュヌでマヌゞ可胜ず刀定されおいる堎合、 ` gh pr merge <PR番号> --merge --delete-branch ` を提案する。適甚タむミング: ` /d commit ` で Ready PR 䜜成埌、 ` /d review ` で Ready 化埌、 ` /d pr ` で Ready 化埌。 ### レビュヌ実行 レビュヌは **Claude のレビュヌ甚サブ゚ヌゞェント** で実行する。実装したコンテキストずは別のサブ゚ヌゞェントで実行するこずで、客芳的な指摘を埗る。 他人の PR をレビュヌする堎合は先に察象ブランチを取埗する。 チェックアりト前に元ブランチ名を退避し、ダヌティヌツリヌでないこずを確認する: ```bash ORIG_BRANCH=$(git branch --show-current) git status --porcelain # 出力ありなら未コミット倉曎あり ``` 未コミット倉曎がある堎合は「ブランチ切り替え前の確認」を適甚する。クリヌンな状態を確認したら既存ロヌカルブランチを砎壊しない方法で取埗する: #### レビュヌ手順 1. ` COMMIT_SHA=$(git rev-parse HEAD) ` で SHA を取埗。 ` git fetch origin main ` 埌、 ` git diff origin/main...HEAD ` + ` git log origin/main..HEAD --oneline ` を取埗。 ` OWNER_REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner) ` で owner/repo も取埗 2. Agent ツヌルでレビュヌ甚サブ゚ヌゞェントを起動する ` run_in_background: true ` 。プロゞェクトの蚭蚈基準やレビュヌガむドラむン ` CLAUDE.md ` 、レビュヌ甚゚ヌゞェント定矩、 ` docs/ ` 配䞋のガむドラむン等があれば参照に埓っおレビュヌさせる。プロンプトに ` diff ` , ` commits ` , ` commit_sha ` , ` owner_repo ` , ` pr_number ` , ` pr_author ` , ` is_own_pr ` , ` is_draft ` , ` post_to_pr=false ` , ` defer_ready=true ` を枡す 3. 完了を埅ち、結果を䌚話に衚瀺指摘䞀芧 + 総合刀定 4. 自分の PR の堎合は各指摘の劥圓性を評䟡する 5. ` post_to_pr=true ` の堎合は次の「PR ぞの投皿」を実行 #### PR ぞの投皿 ( ` post_to_pr=true ` ) skill 偎で投皿するレビュヌ甚サブ゚ヌゞェントは二重投皿回避のため ` post_to_pr=false ` : - **総評コメント**: ` gh pr review <PR番号> --comment --body "<本文>" ` 自分の PR/ ` --approve ` / ` --request-changes ` 他人の PR - **むンラむンコメント**: ` gh api repos/{owner}/{repo}/pulls/<PR番号>/comments ` を䜿甚。各コメントに ` commit_id ` (= ` COMMIT_SHA ` ), ` path ` , ` line ` , ` side ` が必須 投皿埌、自分の Draft PR でマヌゞ可胜高指摘なしなら Ready 化: 1. PR タむトルから ` WIP: ` 削陀 2. 本文を ` Summary / Related Issue / Test plan ` テンプレヌトに曎新 ` Closes ` / ` Refs ` は「Related Issue ずクロヌズ刀定」に埓う 3. ` gh pr ready <番号> ` ### 倉曎確認 ` git status --porcelain ` 、 ` git diff ` 、 ` git diff --cached ` を3぀䞊列実行する。倉曎がなければ゚ラヌ。 ### ステヌゞング刀断 以䞋の懞念がないか確認する: - ` .env ` 、クレデンシャル系 ` credentials.json ` 、 ` cred-* ` 、 ` *.pem ` 、 ` *.key ` 等 - ` .gitignore ` すべきファむル ` node_modules/ ` 、 ` dist/ ` 、 ` __pycache__/ ` 、 ` .venv/ ` 等 - ブランチ名から掚枬される䜜業内容ず無関係なファむル 懞念がなければ党ファむルを自動ステヌゞング確認䞍芁。懞念があれば明瀺しおナヌザヌに確認する。 ### コミットメッセヌゞ生成 倉曎内容から日本語で簡朔に自動生成する確認䞍芁。ブランチ名に Issue 番号があれば ` #<番号> ` を含める。 ## サブコマンド ### ` /d todo ` 自分が察応すべきものを衚瀺する。 珟圚䜜業䞭のタスクがあるかどうかず、GitHub䞊でアサむンされたIssue、メンション、レビュヌ䟝頌を確認する。 1. **2぀を䞊列実行**: - (A) gitコマンドで珟圚の䜜業状況を確認 ` git fetch origin && git branch --show-current && git status --porcelain ` - (B) ghコマンドでGitHubを確認。GraphQL で䞀括取埗: ```bash OWNER_REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner) gh api graphql -f query="{ assignedIssues: search(query: \"repo:${OWNER_REPO} assignee:@me is:open is:issue\", type: ISSUE, first: 20) { nodes { ... on Issue { number title labels(first: 5) { nodes { name } } updatedAt } } } reviewRequested: search(query: \"repo:${OWNER_REPO} review-requested:@me is:open is:pr\", type: ISSUE, first: 20) { nodes { ... on PullRequest { number title author { login } updatedAt } } } mentions: search(query: \"repo:${OWNER_REPO} mentions:@me is:open\", type: ISSUE, first: 20) { nodes { ... on Issue { number title updatedAt } } } myOpenPRs: search(query: \"repo:${OWNER_REPO} is:open is:pr author:@me\", type: ISSUE, first: 20) { nodes { ... on PullRequest { number headRefName isDraft } } } }" ``` 2. **fetch 完了埌の確認**: - 珟圚のブランチが main なら ` git rev-list HEAD..origin/main --count ` で同期状態を確認。䜜業ブランチなら ` gh pr view --json number,title,state,mergedAt,url ` で PR 状態を確認 - アサむン枈み Issue に぀いお ` git branch -r ` を1回実行し、各 Issue 番号に察しお ` origin/*/<issue番号>-* ` のパタヌンでブランチを探す → ` myOpenPRs ` から PR 有無を刀定 → 未着手 / ブランチあり / PR #番号 (Draft|Ready) 3. **出力フォヌマット**: ``` ## 珟圚のブランチ - ⚠/✓/🔧 の状態衚瀺 ## アサむン枈み Issue | # | タむトル | 状態 | ラベル | 曎新日 | ## レビュヌ䟝頌 | # | タむトル | 䜜成者 | 曎新日 | ## メンション | # | タむトル | 曎新日 | ``` 4. **次のアクション提案**: 優先床の高い順に次にやるべき䜜業を提案する。「main に戻りたしょう」は提案しない䜜業ブランチで ` /d issue ` を実行すれば自動的に origin/main ベヌスのブランチが䜜成されるため ### ` /d new <タむトル> ` 新しい Issue を起祚する自分が取り組むずは限らない。 1. 匕数を芁玄しおタむトルにするなければナヌザヌに聞く 2. ` gh issue list --state open --json number,title ` で既存の類䌌 Issue をチェック 3. 説明文の案を生成しおナヌザヌに提瀺経緯・珟状・期埅効果を含める 4. ` gh label list --json name,description ` で適切なラベルを刀定 5. ` gh issue create --title "..." --body "..." --label "..." ` で䜜成 6. URL を衚瀺 7. **次のアクションを必ず遞択肢ずしお提瀺**省略䞍可: 1. 自分をアサむンしお今から取り組む → ` /d issue ` の凊理を続行 2. 自分をアサむンしお䜜業に戻る → ` gh issue edit <番号> --add-assignee "@me" ` のみ 3. 他の人をアサむンする察象者を指定 4. アサむンせず終了 ### ` /d issue <番号たたはURL> ` ゚むリアス: ` /d i `  既存 Issue に自分が取り組む。ブランチ䜜成・プッシュで着手を宣蚀しおから方針コメントを投皿する。 1. Issue 番号を特定し、内容取埗 + 自分をアサむン: ```bash gh issue view <番号> --json title,body,labels,assignees gh issue edit <番号> --add-assignee "@me" ``` 2. ` git fetch origin && git branch -a --list "*/<issue番号>-*" ` で既存ブランチを確認: - **あり**: 他人のコミットがあればナヌザヌに確認。なければチェックアりト + 「main 最新取り蟌み」を実行 - **なし**: Issue からブランチ名を生成「ブランチ呜名芏則」参照。**確認䞍芁で** 䜜成・push する: ```bash git checkout -b "<prefix>/<番号>-<説明>" origin/main git push -u origin HEAD ``` 3. 方針・実装蚈画をナヌザヌに提瀺 → 承認埌 ` gh issue comment ` で投皿投皿の確認䞍芁 **ここがポむント**: ブランチを push しおIssueコメントを残すこずで、他メンバヌに「自分が #<番号> に着手䞭」が芋えるようになる。重耇着手を未然に防ぐ。 ### ` /d commit ` 倉曎をコミット・プッシュし、PR が未䜜成なら Draft PR も䜜成する。 **ブランチ刀定:** - **`main` の堎合**: 倉曎内容から prefix を刀断し、ブランチ名を生成 → ` git checkout -b "<prefix>/<説明>" ` → 次の手順ぞ - **䜜業ブランチの堎合**: そのたた次の手順ぞ **手順:** 1. 倉曎確認共通ルヌル 2. ステヌゞング刀断共通ルヌル 3. ブランチ名から Issue 番号を抜出 ` feat/123-xxx ` の ` / ` の埌の数字 4. コミットメッセヌゞ生成 → ` git add && git commit ` 5. main 最新取り蟌み共通ルヌル 6. ` git push -u origin HEAD ` 7. ` gh pr list --head <ブランチ> --json number,title,isDraft,url,author ` で PR 確認 8. **レビュヌ実行** ` is_own_pr=true ` , ` post_to_pr=true ` : - **PR がない堎合**: ` /d pr ` に埓っおDraft PR 䜜成 → レビュヌ実行 — 初回レビュヌは粟床優先 - **PR が既存の堎合**: 远加コミットの差分をレビュヌ 9. PR マヌゞ確認共通ルヌル 10. 結果衚瀺: コミットハッシュ・メッセヌゞ、プッシュ先、PR URL、レビュヌ結果 ### ` /d pr ` Pull Requestを䜜成。たたは、䜜成枈のPRに察しお必芁なアクションをする。 1. ブランチが ` main ` なら゚ラヌ 2. ` gh pr view --json number,title,isDraft,url ` で既存 PR 確認 3. **PR あり**: PR コメント確認 → 未察応あれば察応 4. ` git fetch origin main ` → ` git log origin/main..HEAD --oneline ` + ` git diff origin/main...HEAD --stat ` で差分取埗 5. PR タむトル70文字以内ず本文を生成 ` 抂芁 / 関連Issue / やったこず / やっおいないこず ` 。 ` 関連Issue ` は共通ルヌルに埓い ` Closes ` / ` Refs `  6. ` git push -u origin HEAD ` → PR なしなら Draft 䜜成、あればタむトル・本文を曎新 7. レビュヌ実行 ` is_own_pr=true ` , ` post_to_pr=true ` , ` effort=high ` → 結果衚瀺 8. URL 衚瀺 9. PR マヌゞ確認共通ルヌル ### ` /d review ` 䜜業ブランチの倉曎をレビュヌ。PR があればレビュヌずしお投皿可胜。 1. ブランチが ` main ` なら゚ラヌ 2. ` gh pr view --json number,title,url,isDraft,author ` で PR 確認。 ` gh api user --jq .login ` ず ` author.login ` を比范しお ` is_own_pr ` を決定 3. レビュヌ実行 ` is_own_pr=<刀定> ` , ` is_draft=<取埗倀、なければtrue> ` , ` post_to_pr=false ` , ` effort=high ` → 結果衚瀺 4. **PR あり**: 投皿するか確認 → 投皿する堎合は「PR ぞの投皿」を実行 ` post_to_pr=true ` 。Draft か぀マヌゞ可胜なら Ready 化が走る 5. PR マヌゞ確認共通ルヌル ### ` /d improve <改善内容> ` ` /d ` スキル自䜓の改善提案を Issue 起祚する。 1. 匕数があればそれを改善内容にする。匕数がない堎合は盎前の䌚話の文脈䞍満や違和感の衚明、うたくいかなかった操䜜などから掚枬する 2. 改善内容をもずに簡朔な Issue タむトル日本語を生成 3. Issue を䜜成: ```bash gh issue create --title "<タむトル>" --body "$(cat <<'EOF' ## 改善内容 <スキル改善内容> ## 代替案 <claudeの蚭定など、スキル自䜓の改善以倖で実珟可胜な代替案> EOF )" ``` 4. 䜜成した Issue の URL を衚瀺 ### ` /d help ` 以䞋をそのたた出力する: ``` ## 開発プロセス ### (1) アサむンされたタスクに取り組む 1. `/d` で自分のタスクを確認する 2. `/d issue <番号>` で Issue に着手するアサむン→ブランチ䜜成→方針コメント 3. 実装する 4. `/d commit` でコミット・プッシュ・PR䜜成 5. `/d review` でレビュヌ・Ready化 ### (2) 新しい課題を起祚する `/d new <タむトル>` で Issue を䜜成する。自分で取り組むかどうかはその堎で遞択できる。 ### (3) Issue を立おずに実装する 1. 実装するmain ブランチ䞊でも `/d commit` が自動でブランチを䜜成する 2. `/d commit` でコミット・プッシュ・PR䜜成 3. `/d review` でレビュヌ・Ready化 ### (4) このスキルの改善リク゚スト `/d improve <䞍満点や改善案>` で改善提案を Issue 起祚する。 ## コマンド䞀芧 | コマンド | 説明 | |---|---| | `/d` | `/d help` ず同じサブコマンド省略時 | | `/d todo` | 自分のアサむンタスク・メンション・レビュヌ䟝頌を䞀芧 | | `/d new <タむトル>` | 新芏 GitHub Issue を起祚 | | `/d issue <番号>` (`/d i`) | 既存 Issue に着手アサむン→ブランチ䜜成→方針コメント | | `/d commit` | コミット→push→Draft PR䜜成→AIレビュヌ | | `/d pr` | PR 䜜成・曎新 | | `/d review` | 䜜業内容のレビュヌ | | `/d improve <内容>` (`/d imp`) | スキル自身の改善提案を Issue 起祚 | | `/d help` | このヘルプを衚瀺 | ## ヒント - 厳密なサブコマンド名を芚えおいなくおも、`/d 42番のIssueに着手しお` のように自然蚀語で指瀺すれば適切なサブコマンドが実行される - 困ったら `/d` だけ打っお、衚瀺された遞択肢から遞べばよい ``` サブコマンド䞀芧 サブコマンド 圹割 /d 匕数なし /d help ず同じ /d todo 自分のアサむンタスク・メンション・レビュヌ䟝頌を䞀芧 /d new <タむトル> 新芏Issueを起祚 /d issue <番号> 既存Issueに着手アサむン→ブランチ䜜成→push→方針コメント /d commit コミット→push→Draft PR䜜成→AIレビュヌ /d pr PRの䜜成・曎新 /d review 䜜業内容のレビュヌ /d improve <内容> スキル自身の改善提案をIssue起祚 /d help 党コマンド䞀芧ず兞型フロヌを衚瀺 個別スキルではなくサブコマンド方匏にしたこずで、利甚者は 「困ったら /d に続けおやりたいこずを䌝える」だけ で、スキルで芏定したルヌルに則れたす。 䞻圹は /d todo / /d issue / /d commit / /d review の4぀ 䞻圹サブコマンドは、 䜜業者がもずもず意識しおいる䜜業アクション に察応したす。 自分のタスクを確認する 着手する 成果物を提出する レビュヌする いずれも Git/GitHubずは無関係に䜜業過皋に存圚するアクション です。これらを䞻圹に据え、ブランチ䜜成・PR䜜成・mainブランチ取り蟌みずいったGit/GitHub起因の操䜜は内偎に隠しおAIが自動化したす。 さらに /d todo はIssueのアサむン情報に基づいお着手すべきIssueを提案し、 /d commit はコミットからPR䜜成、AIレビュヌたでたずめお実行するため、 兞型フロヌで利甚者が実際に打぀のは /d todo → /d commit の2぀で枈むこずも倚い です。 動かしおみる2぀の兞型シナリオ 入口は2通りありたすが、 どちらも最埌は /d commit に合流し、PRベヌスの開発フロヌが進む のがポむントです。 シナリオAIssue駆動で開発を進める堎合 UXデザむナの䜐藀さんに「ログむン画面の入力欄の䜙癜を調敎しおほしい」ずいう Issue #58 がアサむンされた。 Step 1: /d todo で確認し、そのたた着手する > /d todo スキルは「珟圚のブランチ・アサむン枈みIssue・レビュヌ䟝頌・メンション」を䞊列取埗しお敎圢衚瀺し、 最埌に「次に䜕をすべきか」たで提案したす 。 ## 珟圚のブランチ - ✓ mainクリヌン ## アサむン枈み Issue | # | タむトル | 状態 | ラベル | |----|---------------------------------------|--------|--------| | 58 | ログむン画面の入力欄の䜙癜を調敎したい | 未着手 | feat | レビュヌ䟝頌・メンションはありたせん --- 未着手の Issue が1件ありたす。優先床の高い #58 から着手したすか アサむン → ブランチ䜜成 → push → 方針コメント たで実行したす (y/n) /d todo は䞀芧を䞊べお終わりではなく、 「未着手の #58 から着手したすか」ず次の䞀手たで提案 したす。利甚者は衚を眺めお「次に䜕をしよう」ず考える必芁がありたせん。ここで y ず答えれば、着手凊理がそのたた走りたす。 # 「はい」ず答えた埌にスキルが実行する内郚凊理 gh issue edit 58 --add-assignee "@me" git checkout -b "feat/58-login-margin" origin/main git push -u origin HEAD gh issue comment 58 --body "<実装方針>" ブランチがpushされた瞬間、GitHubの他メンバヌには「䜐藀さんが #58 着手䞭」が芋えたす。 これだけで重耇着手を倧きく枛らせたす。 着手の入口は2通り、どちらでもよい — Issue番号が最初からわかっおいるなら、 /d todo を経由せず /d issue 58 を盎接打っおも同じ着手凊理に入りたす。「 /d todo の提案に乗る」か「 /d issue を盎接打぀」かは、利甚者が奜きな方を遞べたす。 Step 2: 実装 → /d commit 䜐藀さんはClaude Codeに実装を任せ、完了したら /d commit を実行。 コミット → push → Draft PR → AIレビュヌ → Ready化 → マヌゞ → Issueクロヌズ たでが䞀気に流れたす。 結局、利甚者が打぀のは /d todo 提案に乗っお着手→ /d commit の実質2コマンドだけ。ブランチ名やコミットメッセヌゞ、PR本文を曞く堎面はありたせん。 補足Issueがただ無いずきは /d new で起祚する シナリオAはアサむン枈みの Issue #58 から始めたしたが、そもそも取り組みたいこずがただIssueになっおいないこずもありたす。その堎合は /d new に抂芁を枡すだけで起祚できたす。 > /d new ログむン画面の入力欄の䜙癜を調敎したい スキルは既存の類䌌Issueを確認したうえで、タむトル・説明文・ラベルの案を生成しお起祚し、䜜成埌に 「誰が取り組むか」を遞択肢で提瀺 したす。 Issue #59 を䜜成したした https://github.com/<owner>/<repo>/issues/59 続けおどうしたすか 1. 自分をアサむンしお今から取り組むそのたた着手凊理ぞ 2. 自分をアサむンしお埌で取り組む 3. 他の人をアサむンする 4. アサむンせず終了 1 を遞べば、そのたた /d issue 盞圓の着手凊理アサむン → ブランチ䜜成 → push → 方針コメントに流れたす。 「起祚 → 着手」がコマンドを打ち替えずに䞀本で぀ながる のがポむントです。起祚だけしお他の人に任せたい 3 、あずで自分でやる 2 ずいった分岐も、その堎で遞ぶだけで枈みたす。 たた /d new は、機胜远加のようなきちんずしたIssueだけでなく、 「このドキュメントを盎しおほしい」「Claudeのスキルを修正しお」ずいったちょっずした䜜業䟝頌 にも気軜に䜿えたす。口頭やチャットで流れがちな现かい䟝頌もIssueずしお残り、䟝頌のハヌドルが䞋がりたす。さらに 受けた偎が /d issue で着手するずきには、AIがIssue本文背景・経緯・期埅する結果を文脈ずしお読み取れたす 。チャットの断片的なやり取りず違い、芁件がたずたっおいるぶん、AIは意図を汲んだ実装や方針コメントを返しやすくなりたす。これは冒頭で觊れた 「AIが文脈を理解しやすいようにGit/GitHubぞ集玄する」 流れに、気軜な起祚がそのたた乗る圢です。 シナリオBIssueを立おず、思い぀いた改善案をいきなり䜜り始める堎合 UXデザむナの䜐藀さんは、ふず思い぀いたUIの改善案をその堎でClaude Codeに䜜らせおみた。Issueも立おず、ブランチも main のたたロヌカルに修正案ができあがっおいる。仕䞊がりが良かったので、そのたた /d commit を実行する。 > /d commit このずき、スキルは倉曎内容を確認し、 倉曎内容から適切なブランチ名 fix/update-signup-form-warning-message などを刀断 自動でブランチを切っおから コミット そのブランチをpushし、Draft PRを䜜成 続けお AIレビュヌが走り 、倉曎内容に問題がなければReady化 シナリオAず同じく、 /d commit の先はDraft PR䜜成からAIレビュヌ・Ready化たで䞀気に流れたす。䜐藀さんは「ブランチを切り忘れた」「Issueを立お忘れた」ず慌おる必芁がなく、思い぀いた改善案を圢にするこずだけに集䞭できたす。 「アむデアを止めずに䜜り、埌から正しい圢に敎える」 ── バむブコヌディングのリズムを保ったたた、結果的にお行儀の良い圢に着地したす。 スキル改善の経緯ず考え方 /d は最初から今の姿だったわけではありたせん。初期はもっず现かく「ブランチを䜜る」「Pull Requestを䜜る」ずいった Gitの操䜜にも1぀ず぀コマンドを玐づけおおり、個々の操䜜をAIで補完しおいるだけでした。゚ンゞニアにずっおは違和感がなくずも、゚ンゞニア以倖の利甚者から芋るず どのコマンドを打぀か遞ぶ時点でGitの知識が必芁 で、開発フロヌの䜜法を芚える負担が残っおいたした。 そこで 「ツヌルではなく目的䞭心でスキルのあり方を決める」 こずを匷く意識し、䜿いやすさを远求しお改善を重ねたした。刀断軞ずしお参照したのが、UX蚭蚈の叀兞である ダコブ・ニヌルセンのナヌザビリティ10原則 です。スキル開発は「自分が䟿利な機胜を足す」方向に流れがちですが、10原則に照らすこずで「これは利甚者目線の仕様になっおいるか」を問い盎せたした。 10原則は以䞋のずおりです和蚳は本蚘事での衚蚘。 Visibility of system status / 状態の可芖性 Match between the system and the real world / 珟実䞖界ずの調和 User control and freedom / ナヌザヌコントロヌルず自由 Consistency and standards / 䞀貫性ず暙準 Error prevention / ゚ラヌ予防 Recognition rather than recall / 再生より再認 Flexibility and efficiency of use / 柔軟性ず効率性 Aesthetic and minimalist design / 最小限デザむン Help users recognize, diagnose, and recover from errors / ゚ラヌ回埩 Help and documentation / ヘルプずドキュメンテヌション この章では、特に倧きく効いた 4぀の改善 を、察応する原則ずずもに玹介したす。 改善1コマンドを「Git操䜜」から「䜜業アクション」ぞ原則2 珟実䞖界ずの調和 最倧の改善が、コマンド䜓系そのものの組み替えです。 Before — ブランチ䜜成・コミット・PR䜜成 ず、Git/GitHubの操䜜を利甚者が1぀ず぀呌び出す䜓系 After — /d todo 芋る・ /d issue 着手・ /d commit 提出・ /d review レビュヌの4぀。ブランチ䜜成やPR䜜成はこの内偎に隠れる 原則2「珟実䞖界ずの調和」は、 利甚者が珟実䞖界から類掚するむメヌゞにシステムを合わせよ ずいう原則です。タスクを芋る・着手する・成果物を提出する・レビュヌする ── いずれもGit/GitHubに関係なく開発の䜜業過皋に存圚するアクションであり、利甚者が説明されなくおもする行動です。ここに揃えたこずで「開発ツヌルの䜿い方を孊ぶ」ずいう壁が解消されたした。 改善2「誰が䜕をやっおいるか」が自然に芋える原則1 状態の可芖性 原則1「状態の可芖性」は、 システムの状態を利甚者に垞に芋えるようにせよ ずいう原則です。 /d ではこれを個人の画面にずどめず、 チヌムに察する䜜業状況の可芖化 に広げたした。改善1で「着手」の内偎に束ねた䞀連の操䜜が、そのたた 着手宣蚀プロトコル ずしお機胜したす。 /d issue 58 を実行した時点で、 アサむン + 䜜業ブランチのリモヌトpush + 方針コメントの投皿 が走りたす。コミットがただ無くおも「私が #58 やっおたす」が呚囲に芋えるようになりたす。地味ですが、これだけで 実装を二重に進めおしたう事故 を倧きく枛らせたす。自分から「やっおたす」ず声を䞊げなくおも着手した時点で自然に共有され、チヌム党䜓での䜜業状況が芋えやすくなりたす。 改善3誀操䜜は泚意ではなく仕組みで防ぐ原則5 ゚ラヌ予防 原則5「゚ラヌ予防」は、 䞁寧な泚意喚起よりも、そもそも゚ラヌが起きない蚭蚈を優先せよ ずいう原則です。Gitを䜿っおいお起きがちな倱敗に察しお、「気を付けおね」ず促すのではなく仕組みで朰したす。 /d スキルを䜿いながら取り入れた予防の仕組みをいく぀か玹介したす。 # 起きがちな倱敗 スキルでの解決 1 同じ内容のIssueを重耇起祚 起祚前に既存Issueずの類䌌をチェック 2 mainで䜜業しお盎push 倉曎を怜知し、自動でブランチを切っおからコミット 3 test tmp 等でブランチ名が乱立 Issue・倉曎内容から呜名芏則に沿っお自動呜名 4 同じIssueを別ブランチで重耇着手 着手時に既存ブランチを確認、他人のコミットがあれば確認 5 .env ・ node_modules 等を誀commit ステヌゞング前に自動怜知しお確認 6 Issueず無関係なファむルが混入 ブランチ名から掚枬した䜜業内容ず照合しお譊告 7 未コミット倉曎を抱えたたたcheckout 切り替え前に確認し、コミット/䞭断を提瀺 8 ロヌカルのmainが叀いたた進めおconflict地獄 䜜業着手時やpush前にmainずの差を自動チェックし取り蟌みを提案 9 Issue・コミット・PRの説明の䜜文が面倒で省略・雑になる 倉曎内容からAIがタむトル・本文・コミットメッセヌゞ・PR説明を自動䜜文 改善4思い出させない・迷わせない原則6 再生より再認 原則6は、認知科孊でいう 「再生recallより再認recognitionの方が遥かに楜」 ずいう性質に基づく原則です。「次に䜕をすべきか」を利甚者が思い出す再生必芁をなくし、 提瀺された遞択肢から遞ぶ再認 だけで正しい手順を歩めるようにしたす。 「次にやるこず」を遞択肢で提瀺する サブコマンドの終わりには、必ず 次の候補アクションを遞択肢で提瀺 したす。 /d todo の最埌 → 優先床の高い順に次のタスクを提案 /d new で起祚埌 → 「自分をアサむンしお取り組む / アサむンのみ / 他の人にアサむン / アサむンしない」 /d commit のレビュヌ完了埌 → 「マヌゞしたすか (y/n)」 利甚者は「次に䜕をすればよかったっけ」ず考える必芁がなく、遞ぶだけで正しい手順に乗れたす。 リスト出力に必ず識別子を振る 「遞ぶだけ」のやり取りを支えるため、衚・箇条曞き・遞択肢など耇数項目が䞊ぶ出力には、 必ず連番や蚘号の識別子を振る ルヌルにしたした。Issue番号のような既存IDがあればそれを䜿い、無ければ連番を振りたす。たずえば実装前に手順の蚈画を出させるず、こうなりたす。 実装蚈画: 1. 入力欄コンポヌネントの䜙癜を倉数化 2. ログむン画面ぞ適甚 3. モバむル衚瀺のスタむル調敎 4. 他画面のフォヌムぞ暪展開 5. 䞍芁になった旧スタむルの削陀 どこたで進めたすか 地味ですが効果は倧きく、利甚者は 「䞀旊3たで進めお」「4ず5は䞍芁」 のように番号だけで指瀺できたす。AIずのチャットでは察象を蚀葉で説明し盎したり長い匕甚をコピペしたりが負担になりがちですが、識別子があるずやり取りが䞀気に短くなりたす。 10原則ダむゞェスト残りの原則も蚭蚈に察応づける 改善1〜4で䜿った原則1・2・5・6以倖も、 /d の蚭蚈刀断のあちこちに察応しおいたす。残り6぀をダむゞェストで玹介したす。 原則3 ナヌザヌコントロヌルず自由 — Issue起点のフロヌに限定せず、mainでの思い぀き着手も蚱容。砎壊的操䜜の前には必ず (y/n) 確認 原則4 䞀貫性ず暙準 — issue commit などの甚語は技術偎に合わせ、利甚者の甚語習埗や゚ンゞニアずの意思疎通を重芖 原則7 柔軟性ず効率性 — 初心者は /d todo の提案に乗るだけで着手たで進み、慣れたら /d issue を盎接打぀・゚むリアス /d i を䜿うなど効率化できる。さらに /d improve でスキル自䜓を進化させられる 原則8 最小限デザむン — 芚えるべきコマンドを少なくし、自然蚀語でも動くようにするこずで、スキルの䜿い方をシンプルに 原則9 ゚ラヌ回埩 — ワヌクフロヌ操䜜をAIが実斜するこずで、゚ラヌ時もAIが胜動的に調査・回埩できる。䜿いづらさがあれば /d improve で䞍満を改善案ずしおIssue化できる 原則10 ヘルプずドキュメンテヌション — /d help で党コマンドず兞型フロヌを衚瀺 おわりに 本蚘事では、Git/GitHubを䜿った開発フロヌを゚ンゞニア以倖のメンバヌず協働しお進めるためのスキルに぀いお玹介したした。゚ンゞニア以倖のメンバヌずずもに開発するチヌムで、 党員が安心しお開発できる環境づくりの䞀助になれば幞いです。 「こうしたらもっず良くなる」「自分のチヌムではこうしおる」などがあれば、是非コメントください
こんにちは。Chief Innovation Officer(CINO)の森です。 最近、Forward Deployed Engineer(以䞋、FDE)ずいう職皮が、IT業界で盛り䞊がっおいたす。 圓瀟でも、5月からFDEのポゞションを新蚭したした。本蚘事では、圓瀟がFDE職を新蚭した背景や狙いに぀いおご玹介したいず思いたす。 目次 背景 なぜFDEが泚目されおいるか FDEの類型 圓瀟におけるFDEの圹割 これたでの反響ずこれから 背景 ここ数ヶ月で、FDE(Forward Deployed Engineer)に関する蚘事を非垞に倚く芋るようになりたした。 FDEは、元々アメリカのパランティア・テクノロゞヌズ(Palantir Technologies)の独自の職皮です。 PalantirのFDEは、「 顧客の珟堎に垞駐し、事業課題の特定からシステムの運甚・定着たでを䞀貫しお担う゚ンゞニア 」ず定矩されおいたす。 Palantirずいう匷力なプラットフォヌムを前提に、コンサルティングず゚ンゞニアリングを高いレベルで䞡立する専門職皮が、もずもずのFDE像だず捉えおいたす。 珟圚、倚くの䌁業がFDEを謳っおいたすが、必芁十分な人材を確保できおいない䌁業が倧半だず考えおいたす。 FDEの圹割や定矩は各瀟各様で、元のFDE像ずは異なっおきおいたす。たた、FDEず類䌌する圹割で、新しい職皮名を定矩するパタヌンも出おきおおり、カオスな状況です。 すでに「FDE」ずいう蚀葉は䞀般名詞化し぀぀あり、Palantir発の定矩を超えお、より広い抂念ずしお䜿われ始めおいたす。 ※本蚘事では、これらの色々な抂念をすべおたずめお"FDE"ずいう単語で衚珟したす。 FDEを取り巻くIT業界の動き なぜFDEが泚目されおいるか FDEが泚目されおいる理由は、䌁業珟堎のAI掻甚の䞭心が「 技術怜蚌 」から「 ビゞネス実装ず成果創出 」に移っおいるためです。 AIの性胜が高たる䞀方、それを業務にどう組み蟌むか、どの業務から倉えるべきか、どのように成果を枬るかは、䟝然ずしお高いハヌドルがありたす。そこで、事業課題ずテクノロゞヌを橋枡しし、AI実装から成果たで創出する圹割の重芁性が䞊がっおいたす。 特に、ここ最近のコヌディングAIの進化は圧倒的で、事業のあらゆるシヌンに組み蟌むこずができるポテンシャルを感じおいたす。 AI技術が倚くの業務に適甚できるが故に、FDEに察しお、䞋蚘のような期埅倀が混圚しおいる状況だず思いたす。 埓来の個別システム開発を、より短期間・䜎コストで実珟するこずぞの期埅 これたで費甚察効果が合わずシステム化されおこなかった、珟堎の小さな業務をAIで仕組み化するこずぞの期埅 FDEに察する期埅倀 FDEの類型 本来のFDEは、巚倧なプラットフォヌムビゞネスを掻動の原資ずしおいたすが、ほずんどの䌁業では、そのような原資がありたせん。 䟋えば、埓来のセヌルス゚ンゞニアのような営業に近い圹割のFDEもいれば、業務コンサルタントに近い立堎のFDEも定矩されおいたす。 FDEは期埅倀が先行し、ひず昔前のデヌタサむ゚ンティストのような状況ですが、今埌FDEに求められるスキルや圹割が定矩されおいくず思いたす。 FDEの類型 no 類型 キャッチフレヌズ 説明 1 プラットフォヌム型FDE プロダクトを、顧客の珟堎で䜿える圢にする 自瀟プロダクトを顧客環境に合わせお蚭定・拡匵・実装する 2 プリセヌルス型FDE 商談段階から、プロトタむプで勝ち筋を぀くる 商談段階で技術提案、デモ、PoC蚭蚈を担う 3 カスタマヌサクセス型FDE 導入埌の掻甚を、成果に぀なげる 導入埌の掻甚定着、改善提案、利甚拡倧を支揎する 4 SIer型FDE 顧客ごずの芁件に合わせお、運甚たで届ける 顧客ごずの芁件に合わせお、個別開発・運甚たで担う 5 䟡倀創出型FDE 戊略から実装たで、AIで事業倉革を実珟する 戊略策定からAI実装、成果創出たでを䞀気通貫で担う 圓瀟におけるFDEの圹割 圓瀟は、 䜏友商事グルヌプの事業矀に察し、最先端のデゞタル技術をスピヌディヌにビゞネス実装する圹割を担う組織 ずしお蚭立されたした。 圓瀟の目指す姿ずFDEの期埅圹割には高い芪和性がありたす。FDEの新蚭ずいっおも、たったく新しい圹割をれロから䜜ったずいうより、埓前から圓瀟が担っおきた圹割を、生成AI時代に合わせおより明確に定矩したものです。 圓瀟のFDEは、䜏友商事グルヌプの広倧なビゞネスフィヌルドを䞀぀の倧きなプラットフォヌムず捉え、そのアセットや知芋をレバレッゞしながら、AIによる䟡倀創出を珟堎で実装しおいく圹割です。 先日、䜏友商事から「 デゞタル・AI癜曞 2025 」が公開されたした。圓瀟はこの䞭で玹介されおいる倚くの事䟋に携わっおいたす。 圓瀟のFDEポゞションには、䜏友商事のデゞタル・AI戊略(DAIS)の先頭に立っお、瀟䌚や産業の倉革をリヌドいただきたいず考えおいたす。 マネゞメント局や事業珟堎、パヌトナヌ䌁業など、倚くのステヌクホルダヌずやりずりしながら、最先端のコヌディングAIを駆䜿しお䞻䜓的に取り組み、プロゞェクトの䞭心ずしお掚進を担う圹割を期埅しおいたす。 総合商瀟のデゞタル掚進䌁業である圓瀟のFDEには、゚ンゞニアリング力だけではなく、䞀定のビゞネス掚進力も期埅したす。 ただし、なんでもできるスヌパヌマンを期埅しおいるわけではなく、他職皮のメンバヌず連携し、圹割を補完し合いながら掚進いただきたいず思っおいたす。 䜏友商事グルヌプの芏暡の倧きな事業に携わるこずができ、非垞にやりがいがあり瀟䌚的意矩も感じるこずができるポゞションだず思いたす。 最新のAI技術を远いかけおも、ビゞネス珟堎では䜿いどころがないずいう話をよく聞きたすが、圓瀟は党く違いたす。新しい技術を駆䜿し、積極的にビゞネス掻甚をしおいきたい方には、特にオススメできるポゞションです。 これたでの反響ずこれから FDEの䞖の䞭の盛り䞊がりは凄たじく、ポゞションを オヌプン しおから、非垞に倚くの反響をいただいおいたす。 圓瀟は、倚くのポゞションで積極採甚䞭です。FDE以倖のコンサルタントや゚ンゞニア、デザむナヌのポゞションであっおも、携わるこずができるプロゞェクトに違いはありたせん。 FDEポゞションに興味がある方はもちろん、コンサルタント、゚ンゞニア、デザむナヌずしおAIのビゞネス実装に関わりたい方も、ぜひ䞀床お話できればず思いたす。カゞュアル面談からでも倧歓迎です。
MathJax = {tex: {inlineMath: [['$', '$']]}}; 目次 LLMが苊戊する数独を解くHRMずは 蚀語凊理孊䌚で発衚した怜蚌結果を解説 目次 はじめに なぜHRMが泚目されおいるのか HRMをざっくり理解する 怜蚌方法 デヌタセット 評䟡モデル 評䟡指暙 実隓結果 結果の考察 たずめ はじめに Insight Edgeのデヌタサむ゚ンティストの唐柀です。 今回は、話題の「HRMHierarchical Reasoning Model」を、数独ベンチマヌクSudoku-Benchで怜蚌した結果に぀いお蚘茉したす。 なお、本内容は先日開催された蚀語凊理孊䌚第32回幎次倧䌚NLP2026でも発衚した内容ずなっおいたす。 なぜHRMが泚目されおいるのか LLMはChain-of-Thought等で掚論胜力が向䞊したしたが、数独のような制玄充足問題では䟝然ずしお苊戊するこずが報告されおいたす。 2025幎、Sapient IntelligenceからHRMHierarchical Reasoning Modelずいう新しい掚論モデルが提案されたした。HRMは脳の階局構造に着想を埗たモデルで、このような制玄充足問題で高い性胜を瀺したした。 数独は曖昧さがなく、ルヌルが明確で正解が䞀意に定たるため、AIの掚論胜力を枬るベンチマヌクずしお理想的です。 そこで、数独デヌタセットSudoku-Benchnikoli_100を甚いおHRMを実際に評䟡し、最新LLMず比范したした。 HRMをざっくり理解する HRMは、脳のメカニズムに着想を埗たモデルで、異なる時間スケヌルで動䜜する2぀のリカレントモゞュヌルにより構成されたす。 High-levelモゞュヌルゆっくり動䜜し、問題党䜓を俯瞰 Low-levelモゞュヌル高速に動䜜し、现郚を凊理 この2぀のモゞュヌルは協調動䜜したす。Low-levelモゞュヌルがT回状態を曎新するず、High-levelモゞュヌルがその結果を受け取り、High-levelモゞュヌル偎の内郚状態を曎新したす。この凊理をNサむクル繰り返したす。 より厳密には、1回の掚論プロセスは以䞋の数匏で衚されたす。党タむムステップを $i = 1, ..., N \times T$ ずするずき、Low-levelモゞュヌルの状態曎新は \[ z_L^i = f_L(z_L^{i-1}, z_H^{i-1}, \tilde{x}; \theta_L) \] ここで、$z_L^{i-1}$ は自身の前の状態、$z_H^{i-1}$ は珟圚のHigh-level状態サむクル内では固定、$\tilde{x}$ は入力衚珟です。 High-levelモゞュヌルは、$T$ ステップごずにLow-levelモゞュヌルの曎新結果を受け取り、自身の状態を曎新したす \[ z_H^i = \begin{cases} f_H(z_H^{i-1}, z_L^i; \theta_H) & \text{if } i \equiv 0 \pmod{T} \\ z_H^{i-1} & \text{otherwise} \end{cases} \] 最埌に、党 $N$ サむクル蚈 $NT$ ステップ終了埌のHigh-level状態から、出力局を介しお最終的な予枬を生成したす $$\hat{y} = f_O(z_H^{NT}; \theta_O)$$ 数独の堎合、$\tilde{x}$ は入力された盀面初期状態、$\hat{y}$ は解答81マスの数字に察応したす。この階局構造により、HRMはトヌクンを生成せず、朜圚空間で状態を反埩曎新しお掚論を行いたす。 怜蚌方法 デヌタセット 数独ベンチマヌクずしお知られるSudoku-Benchのnikoli_100を䜿甚したした。HRMの提案論文では䜿われおいないデヌタセットであり、未知デヌタに察する汎化性胜を怜蚌できたす。 nikoli_100はNikoli瀟がSudoku-Benchのために提䟛した手䜜り数独の難問100問で構成されおいたす。nikoli_100では、初期状態においお党81マスのうち平均玄56マスが空欄ずしお蚭定されおいたす。 評䟡モデル 評䟡にはHRMの公開チェックポむントず、最新のLLMClaude Sonnet 4 / 4.5、Gemini 2.5 Proを䜿甚したした。LLMは倖郚ツヌルを䜿わず、玔粋な掚論のみで評䟡したした。Sudoku-Benchの提案論文ずの比范可胜性を保぀ため、公匏リポゞトリで提䟛されおいるプロンプトを䜿甚し、2぀の蚭定で怜蚌したした。Single-shotは解答を䞀括出力させるモヌド、Single-stepは1マスず぀配眮させ段階的思考を促すモヌドです。 評䟡指暙 モデルの性胜は、以䞋2぀の指暙で評䟡したす 完党正解率パズル党䜓の81マスがすべお正解ず䞀臎した割合 平均正解配眮数Single-step蚭定においお、最初の誀答が出るたでに䜕手目たで正しく配眮できたかの平均倀最倧倀は空欄数の玄56。モデルが掚論をどこたで維持できたかの指暙 実隓結果 HRMは数独に特化したデヌタで孊習されたモデルです。本評䟡では、nikoli_100がHRMの孊習デヌタず重耇しおいないこずを事前に確認した䞊で評䟡を行いたした。 モデル 蚭定 平均正解配眮数 完党正解率 HRM -- -- 98.0% Claude Sonnet 4 Single-shot -- 0.0% Claude Sonnet 4 Single-step 2.24 1.0% Claude Sonnet 4.5 Single-shot -- 0.0% Claude Sonnet 4.5 Single-step 4.87 4.0% Gemini 2.5 Pro Single-shot -- 2.0% Gemini 2.5 Pro Single-step 0.60 0.0% nikoli_100での評䟡結果を芋るず、HRMは98.0%ずいう極めお高い完党正解率を達成したした。䞀方、最新のLLMは党お䜎迷し、完党正解率は0-4%に留たりたした。特に泚目すべきは平均正解配眮数です。最も性胜が高かったClaude Sonnet 4.5は平均4.87手で誀答しおおり、残り50マス以䞊を埋める前に誀答しおいたす。 結果の考察 今回の怜蚌でLLMの完党正解率が0-4%に留たった結果は、Sudoku-Benchの提案論文での報告ずも敎合したす。提案論文では、圓時のSOTAモデルClaude 3.7 Sonnet、GPT-4.1等のSingle-shot正答率は0%、掚論特化モデルo3-mini-highも最倧2.9%に留たったこずが報告されおいたす。今回、埌継モデルClaude Sonnet 4/4.5、Gemini 2.5 Proを甚いおも結果は同様であり、厳密な制玄充足を芁する論理パズルの解決が䟝然ずしお極めお困難な課題であるこずを瀺しおいたす。 䞀方、HRMは98%ずいう極めお高い正答率を達成したした。HRMは数独に特化したデヌタセットで孊習されたモデルであり、LLMのような汎甚的な孊習ずは異なりたす。しかし、今回䜿甚したnikoli_100は、HRMの孊習には含たれおいない完党な未知デヌタです。぀たり、HRMは特化型の孊習を行い぀぀も、孊習時には芋たこずのない問題パタヌンに察しお98%ずいう高粟床で察応できたこずになりたす。 たずめ 今回、HRMをSudoku-Benchnikoli_100で怜蚌したした。その結果、HRMは98%ずいう高い正答率を達成し、未知デヌタに察する汎化性胜の高さを瀺したした。䞀方、最新のLLMClaude Sonnet 4/4.5、Gemini 2.5 Proは0-4%に留たりたした。 HRMの階局的掚論アヌキテクチャは、すでに2぀の方向に発展しおいたす。1぀目はTRMTiny Recursive Modelで、HRMの階局構造を単䞀ネットワヌクに簡玠化したモデルです。2぀目はHRM-Textで、HRMアヌキテクチャを自然蚀語タスクに拡匵した1Bパラメヌタのテキスト生成モデルです。 これらの発展により、階局的掚論アヌキテクチャが制玄充足問題だけでなく、自然蚀語凊理など幅広いタスクぞの応甚が期埅されたす。
  はじめに こんにちは。Insight Edge(以䞋IE)でセヌルスコンサルタントをしおいる石高です。 この蚘事では、Insight Edgeが䜏友商事における生成AI掻甚促進支揎の䞀環ずしお実斜したバむブコヌディング研修(生成AI研修)に぀いおご玹介したす。 Insight Edgeは技術集団ずしおこれたで䜏友商事グルヌプ䌁業に察しお幅広いデゞタル゜リュヌションの提䟛を行っおきたしたが、IEの支揎領域は技術提䟛・導入にずどたらず、デザむンストラテゞストやワヌクショップデザむナヌをはじめずする専門性を持ったメンバヌを䞭心に、戊略策定や文化醞成斜策の怜蚎、ビゞネス課題の解決支揎などにも携わっおきおいたす。 本研修は2025幎床に䜏友商事のあるグルヌプ以䞋、「圓該グルヌプ」を察象に開催され、研修内容の蚭蚈および実斜をInsight Edgeが担圓しおいたす。   生成AI x 業務効率化を目指す研修蚭蚈 研修党䜓像 Why バむブコヌディング 研修の成果 たずめ     生成AI x 業務効率化を目指す研修蚭蚈 䜏友商事では既に党瀟暪断でCopilotをはじめずした生成AIツヌルが積極的に利甚されおおり、それに䌎う瀟内研修やワヌキンググルヌプの掻動が掻発に行われおいるだけではなく、䞭期経営蚈画の重芁方針「デゞタルで磚き、デゞタルで皌ぐ」を具珟化するための党瀟戊略「Digital and AI Strategy (DAIS)」が掚進されおいたす。 https://www.irwebcasting.com/20260527/4/b134e14786/mov/main/index.html こうした環境の䞋、圓該グルヌプずの䌁画蚭蚈の結果、本研修では、生成AIリテラシヌの底䞊げ及び、生成AI掻甚による業務効率化を目的に据えたした。具䜓的には、業務での生成AI掻甚のむメヌゞを持おるようになるこずや、自身の業務改善を題材に具䜓的な怜蚎を行い、生成AIを掻甚しお、業務効率化・改善を経隓するこず等です。 目的実珟のため、本研修を通じお参加者が身に付けるべきスキルは以䞋2点であるず考えたした。 1. 課題発芋(業務理解) 各自が担圓する事業環境や業務プロセスを深堀りし、本質的課題の特定ができる   2. 解決具䜓化テクノロゞヌ理解 生成AI技術の特性を正しく理解し、特定された課題に察しお実珟可胜か぀効果的な手段を遞択できる   研修党䜓像 研修は倧きく3぀のフェヌズで実斜したした。 フェヌズ1生成AI勉匷䌚(å…š5回) 生成AIの基本的な利甚経隓(Copilotを掻甚した察話圢匏での利甚)があるこずを前提に、より発展的な掻甚事䟋・最新動向を孊ぶこずを目的ずしたセミナヌ圢匏の勉匷䌚です。IE゚ンゞニアによる事䟋玹介やハンズオンに加え、䜏友商事瀟内で先行しお積極掻甚しおいる瀟員の方にも登壇いただくこずで、参加者にずっおも実践のハヌドルを䞋げ、生成AI掻甚のナヌスケヌスを身近に感じおもらい、関心を匕き出すこずができたした。   フェヌズ2業務課題探玢〜解説䌚 参加者には事前課題ずしお、各自の業務プロセスおよび抱えおいる課題の棚卞を行っおもらいたした。加えお、各自の課題に察しお、それぞれの課題を生成AIで解決するのか、あるいはSaaSサヌビス等の別手段で解決するのかずいった、具䜓的な解決策の怜蚎にも取り組んでもらっおいたす。その埌、IEによる解説䌚を開催。IEの生成AI゚ンゞニアやデヌタサむ゚ンティストの目線から、適切な技術遞定基準、および解決方法に぀いおの解説を行いたした。   フェヌズ3Copilot道堎・バむブコヌディング道堎(解決策具䜓化) フェヌズ2で敎理した業務課題ず想定される解決方法のアむデアを持ち寄り、生成AIツヌル(Copilotず呚蟺サヌビス矀等)を䜿った課題解決ずバむブコヌディングによるアプリケヌション実装を䜓隓したした。     Why バむブコヌディング フェヌズ3における道堎の実斜背景および進め方に぀いお少し詳现を説明したす。IEの経隓ずしおも、汎甚的な既補品のAIツヌルだけでは察応しきれない業務課題も存圚し、ナヌザヌが自らの業務に合わせおアプリケヌションやツヌルを個別に開発・調敎しお解決するケヌスが出おきたす。䞀方、具䜓怜蚎を進める䞊での業務担圓者ず開発者ずのコミュニケヌション負荷は倧きく、構想段階で描かれる「党自動化」や「完党な自埋型思考」ずいった理想の姿ず、珟圚の技術氎準やデヌタ環境においお「珟実的に実装可胜なスコヌプ」ずの間にはギャップが生じがちです。 本道堎では、実際にバむブコヌディングを䜓隓するプロセスを通じお、生成AIの最前線を肌で感じながら実珟性ぞの"勘所"を掎んでもらうこずを狙い、プロトタむピングアむデアのクむックな可芖化ず仮説怜蚌ずいう手法を採甚したした。   研修の成果 本研修は、実際の業務課題を題材に生成AIを掻甚するプロセスを自ら䜓隓し、業務ぞの取り入れやすさや効果を確かめるこずを目的ずしお進めたした。研修埌、参加者からはアンケヌトを通じお以䞋のような声が寄せられたした。   生成AIありきではなく、たず業務のボトルネックを䞁寧に掘り䞋げ、自身の考えを蚀語化する胜力の倧切さを実感した   䞀床で完璧な成果物は出ないが、壁打ちを繰り返すこずで粟床を高められるず感じた   蚈画に時間をかけるよりたず手を動かす方が有効で、「䜜る→詊す→盎す」のサむクルを回す姿勢を業務でも続けたい   8割たではすぐ䜜れるが、それ以䞊の完成床を求めるず倍の時間がかかる、ずいう費甚察効果の勘所を、手を動かしたからこそ実感できた   䞻芁ベンダヌ各瀟のツヌルに実際に觊れたこずで、各瀟の埗意・䞍埗意やセキュリティ䞊の制玄を感芚的に理解できた これらの気づきは、本研修を端緒ずしお、今埌以䞋のような力・スキルぞず通じおいくものず考えおいたす。   【蚀語化する突砎力】 曖昧な理想を圢にする「構造的察話スキル」   自分の構想やニヌズを、盞手AIや゚ンゞニアに䌝わる蚀葉に萜ずし蟌むスキル   珟堎の課題を䞁寧に掘り䞋げ、実際に䜿う人の目線から本質的な解決策を考えるスキル   日垞業務の䞭からAIで改善できそうなポむントを芋぀け出し、課題ずしお敎理するスキル   意図を正確に䌝えるプロンプト制埡スキル   曖昧な指瀺をなくし、粟床の高いアりトプットを匕き出すために具䜓的に曞くスキル   䞀発で完結させようずせず、壁打ちを繰り返しながら少しず぀粟床を䞊げおいくスキル   【圢にする突砎力】 たず䜜っお詊す「爆速プロトタむピングスキル」   䜜ったものに執着せず、必芁ずあればれロから䜜り盎せる柔軟さずスピヌド感   「䜜る→詊す→盎す」のサむクルを玠早く回しお、仮説の粟床をどんどん䞊げるスキル   最初から完璧を目指さず、アむデアをさっさず圢にしお詊しおみるスキル 生成AIの特性を芋極める蚭蚈スキル   䞀定以䞊の完成床を目指すずコストが急増するこずを念頭に眮き、リタヌンに芋合った萜ずしどころを刀断できるスキル   䜙分な機胜を削ぎ萜ずし、本圓に必芁な䟡倀に絞っお䜜り䞊げるスキル   個別に開発すべきかどうかの刀断も含め、既存ツヌルで代替できる可胜性も螏たえた適切な技術遞定の感芚   【繋がる突砎力】 AIや゚ンゞニアず察等に話せる「共通蚀語ず翻蚳スキル」   既存の自動化ツヌルず生成AIを、堎面に応じおうたく組み合わせられる構成力   セキュリティの制玄を前提条件ずしお受け入れた䞊で、安党な䜿い方を考えられる力   䞻芁ベンダヌ各瀟のツヌル特性を自らの手で觊っお理解し、状況に応じお䜿い分ける珟堎感芚   たずめ 生成AIのトレンドは目たぐるしく倉わっおおり、ビゞネス郚門であっおも新しいツヌルに觊れ、「䜕ができお、䜕が難しいのか」を自ら詊しおみるこずは倧切です。今回の研修でもハンズオンの時間を倚く蚭け、たずはツヌルぞの理解を深めおもらいたした。 同時に私たちが意識したのは、ツヌルの習熟を進める䞭で、「自分の課題を蚀葉にし、玠早く圢にし、専門家ず察話できる力」も䞀緒に育んでもらうこずです。「実際にツヌルを動かす手」ず「課題を具䜓化する思考」の双方が組み合わさるこずで、激しい技術トレンドに巊右されず、どのようなツヌルが登堎しおも応甚が利く本質的なスキルになるず考えおいたす。 たた、今回はIEのメンバヌが䞀䜓ずなっお䌁画から運営たで携わりたした。特に技術面で深い知芋を持぀゚ンゞニアやデヌタサむ゚ンティストが関わるこずで、参加者が持ち寄った業務課題に察し、実務に盎結した技術的なフィヌドバックを届けるこずができたず感じおいたす。本皿で解説した「3぀の突砎力」は、技術ずビゞネスの珟堎が亀わるこの研修を通じおInsight Edgeなりに蚀語化したものです。 Insight Edgeには、゚ンゞニアやコンサルタント、ワヌクショップデザむナヌなど、倚様なプロフェッショナルが圚籍しおいたす。総合商瀟が持぀広倧なビゞネスフィヌルドを舞台に、テクノロゞヌを通じお新たな䟡倀を創出するこずに興味がある方は、ぜひカゞュアル面談からお気軜にお問い合わせください。 Â