メルカリのClaude Code企業導入ガイド:セキュリティ設定と組織配布の実践戦略

メルカリが「Claude Code Meetup Japan #4」で公開した資料が注目を集めている。エンジニアだけでなく非エンジニアにもClaude Codeを全社展開するにあたって実施したセキュリティ設定と、MDMを活用した組織配布の実践的な戦略が体系的にまとめられている。 Claude Codeがもたらすリスク Claude Codeは非常に強力なツールだが、その強力さゆえにセキュリティリスクも伴う。具体的には以下の操作が可能なため、適切な制限なしに利用すると重大な問題につながりかねない。 ファイルの検索・読み書き・編集 Webページの取得・検索 任意のコマンドの実行(rm -rf や curl など) PCに保存されている認証情報(APIキー、AWSクレデンシャルなど)や重要なファイルに、LLMが直接アクセスできてしまう状態は大きなリスクとなる。 メルカリが実施した5つのセキュリティ対策 メルカリのAI Security Teamはこれらのリスクに対し、以下の5つの対策を実施した。 1. バイパスモードの禁止 --dangerously-skip-permissions などのバイパスオプションを利用禁止にし、ユーザーによる確認ステップを必ず経由させる。LLMが自律的に危険な操作を実行できないようにする基本的な設定だ。 2. 危険コマンドの確認必須化 bash の実行や curl による外部通信など、影響範囲の大きいコマンドは都度ユーザーの確認を求めるように設定する。自動承認させずに人間が内容を確認してから実行させる。 3. 危険な操作の禁止 環境変数の読み込み(APIキー等の漏洩を防ぐ) sudo によるシステム管理者権限での操作 これらを設定レベルで禁止することで、意図しない権限昇格やクレデンシャルの流出を防ぐ。 4. Sandboxによる操作範囲の制限 作業ディレクトリ外へのファイルアクセスを制限 不要なネットワークアクセスを制限 Sandboxを活用することで、Claude Codeの操作範囲を必要最小限に絞り込む。 5. セキュリティポリシーのシステムプロンプトへの組み込み 社内のセキュリティポリシーをClaude Codeのシステムプロンプト(CLAUDE.md など)に直接記述する。LLM自体にセキュリティ意識を持たせる「教育」的なアプローチだ。 組織配布の課題と解決策 全社員に安全な設定を届けるうえで、メルカリが直面した課題がある。エンジニアと非エンジニアで求める設定のニーズが相反するという点だ。 対象 ニーズ エンジニア 柔軟にカスタマイズできる設定 非エンジニア 何も考えなくても安全な初期設定 MDMを活用した属性別の設定配布 メルカリはMDM(Mobile Device Management:端末管理システム)と連携し、社員属性(エンジニア / 非エンジニア)に応じて配布する設定を分離した。 非エンジニア向け: 最も制限が強い安全な設定を自動適用。ユーザー側での変更を不要にする エンジニア向け: 基本的な安全性を担保しつつ、業務に応じたカスタマイズを許容する これにより、全社員が「最初から安全な環境でClaude Codeを使える」状態を実現している。 企業でClaude Codeを導入する際のポイント メルカリの事例から、企業導入に際して押さえておきたいポイントをまとめる。 ...

2026年4月11日 · 1 分

Claude Managed Agents のアーキテクチャ: Brain / Session / Hands の分離設計

前回の記事では Claude Managed Agents の概要と業界インパクトを紹介した。本記事では、Anthropic のエンジニアリングブログ「Scaling Managed Agents: Decoupling the brain from the hands」に基づき、内部アーキテクチャを掘り下げる。 全体アーキテクチャ Claude Managed Agents は4つのコアコンセプトで構成される。 コンセプト 説明 Agent モデル、システムプロンプト、ツール、MCP サーバー、スキルの定義 Environment コンテナテンプレート(パッケージ、ネットワークアクセス、マウントファイル) Session Agent と Environment を参照して起動される実行インスタンス Events アプリケーションとエージェント間でやり取りされるメッセージ(SSE) これらの背後には、Brain / Session / Hands という3層の分離設計がある。 設計思想: OS の抽象化パターン Anthropic はこのアーキテクチャの設計思想を、OS がハードウェアを抽象化した歴史に重ねている。 1970年代のディスクパックでも現代の SSD でも、read() コマンドは同じように動く。ハードウェアの実装が変わっても、その上の抽象化層(プロセス、ファイル)は安定し続けた。 Managed Agents も同じパターンを採用している。Session、Harness、Sandbox というエージェントのコンポーネントを仮想化し、インターフェースは安定させたまま、内部実装を自由に交換できる構造にした。Anthropic はこれを「メタハーネス」と呼んでいる。 なぜこの設計が必要なのか。ハーネスには「モデルが自力でできないこと」に関する前提が埋め込まれるが、モデルの能力が向上するとその前提が陳腐化する。例えば Claude Sonnet 4.5 では、コンテキスト制限が近づくとタスクを早期終了する「コンテキスト不安(context anxiety)」が見られた。そこでハーネスにコンテキストリセットを追加した。しかし Claude Opus 4.5 ではこの振る舞いが消え、リセット機能は無駄な荷物になった。 ...

2026年4月10日 · 3 分

Claude Managed Agents: Anthropicが本番運用可能なエージェント基盤をパブリックベータで公開

2026年4月8日、Anthropicが「Claude Managed Agents」をパブリックベータとして公開した。AIエージェントの本番運用に必要なインフラをすべてマネージドで提供するサービスで、エージェント構築のコストと期間を劇的に削減する。 Claude Managed Agents とは Claude Managed Agents は、AIエージェントの構築・デプロイ・運用に必要なインフラを一括提供する API スイートだ。開発者はモデル、システムプロンプト、ツール、MCP サーバーを定義するだけで、本番レベルのエージェントを稼働させられる。 提供される主な機能: セキュアなサンドボックス: エージェントの実行環境を安全に分離 長時間実行セッション: 数時間にわたるタスクも途中状態を維持しながら処理 状態管理: コンテキストウィンドウの外に永続的なセッションログを保持 マルチエージェント連携: 複数のエージェントが協調して動作するフリート管理 MCP 統合: HubSpot などの外部サービスと即座に連携可能 スコープ付き権限管理: エージェントごとに適切なアクセス制御を設定 platform.claude.com から利用でき、API 従量課金に加えてセッション時間あたり $0.08 の料金が発生する。 エージェント構築市場へのインパクト この発表が業界で大きな反響を呼んでいるのは、エージェント構築の構造そのものを変える可能性があるためだ。 開発期間の短縮 これまでエージェントを本番運用するには、サンドボックス、状態管理、認証、長時間実行、マルチエージェント協調といったインフラを自前で構築する必要があった。Claude Managed Agents はこれらをすべてマネージドで提供するため、月単位だった開発が日単位に短縮される。 既存プレイヤーへの影響 LangChain は Deep Research エージェントだけで1年かけて4つのアーキテクチャを開発してきた。Manus は6ヶ月で5回のハーネス書き直しを行った。Anthropic はこうした領域をファーストパーティのマネージドサービスとして一気に抽象化した形だ。「Claude を本番で安定稼働させる」ことを売りにしていたエージェントスタートアップにとっては、ビジネスモデルの根本的な見直しを迫られる状況と言える。 AWS のサーバーレス革命との類似 企業が求めているのは「エージェントのインフラを構築すること」ではなく「動くエージェント」そのものだ。AWS がサーバー管理を EC2 で抽象化したのと同じ構造で、Anthropic はエージェント構築という市場そのものを縮小させる可能性がある。 既に本番運用している企業 Anthropic の発表によると、Notion、Rakuten、Asana、Sentry がすでに Claude Managed Agents を本番環境で運用している。公式デモのダッシュボードでは、複数のエージェントがフリートとして稼働しタスクを処理している様子が確認できる。 OpenClaw 遮断との関連 発表の4日前、Anthropic は OpenClaw をはじめとするサードパーティ製ハーネスによるサブスクリプション認証情報の利用をブロックした。消費者向け認証レイヤーの上にサービスを構築することを止め、代わりにファーストパーティのマネージドプラットフォームを提供するという戦略が明確になった。 ...

2026年4月10日 · 1 分

Amazon S3 Files GA:消えるアーキテクチャ層と生まれるアーキテクチャ

2026年4月7日、AWSがAmazon S3 Filesを一般提供(GA)しました。S3バケットをNFS v4.1/v4.2のファイルシステムとしてマウントできる機能で、EC2・EKS・ECS・Lambdaのいずれからでも利用できます。 本記事は、ikenyal氏のZenn記事「S3 Filesで消えるアーキテクチャ層、生まれるアーキテクチャ」を参照しながら、S3 Filesが既存のアーキテクチャにどう影響するかを整理します。「何が設定できるか」ではなく「何が不要になり、何が可能になるか」にフォーカスします。 S3 Filesが解こうとしている問題 たとえば、MLチームが学習データの前処理をする場面を考えましょう。元データはS3に置いてあり、pandasで読み込んで加工したい場面です。 pd.read_csv("s3://my-bucket/data.csv") と書けますが、内部ではboto3がGETリクエストを発行してメモリに読み込んでいます。手元の open("./data.csv") とは根本的に異なるI/Oモデルです。 規模が大きくなると、これは「パイプラインのアーキテクチャ課題」になります。 S3からEFS/EBSにコピー → 処理 → 結果をS3に書き戻す この「中間のコピー層」は本来やりたい処理ではなく、ストレージのI/Oモデルの違いを埋めるためだけに存在しています。 S3 Filesはこのギャップそのものを解消します。アプリケーションからS3のデータはローカルのディレクトリに見えます。 1 2 3 # S3 Filesを使うと pd.read_csv("/mnt/s3files/data.csv") # S3のオブジェクトが読まれる df.to_csv("/mnt/s3files/result.csv") # 変更が自動的にS3にコミットされる FUSEベースのツールとの違い 「S3をマウントできる」と聞いて、Mountpoint for Amazon S3やgcsfuseを思い浮かべる方も多いでしょう。S3 Filesは内部構造がまったく異なります。 FUSEベースのツールは、S3 APIの上にファイルシステムの振る舞いを「エミュレーション」するアプローチです。ファイルの一部だけを書き換えるような操作がサポートされず、空ディレクトリの扱いに不整合が出ることもあります。 S3 Filesはエミュレーションではなく、EFS(Elastic File System)という本物のNFSファイルシステムをS3に接続しています。二つの異なるシステムが共存し、その間に明示的な同期レイヤーがある構造です。 「stage and commit」モデル ファイルシステム上での変更は即座にS3に反映されるのではなく、約60秒ごとにまとめてS3へPUTされます(「commit」)。逆に、S3側でオブジェクトが更新された場合は通常数十秒以内にファイルシステム側に反映されます。 これは明確なトレードオフです。「リアルタイムに同期される共有ファイルシステム」ではなく、「数十秒の遅延を許容する代わりに、ファイルとオブジェクトの両方のセマンティクスを壊さない」設計です。 消えるアーキテクチャ層 1. S3 → EFS/EBSのステージングパイプライン 100GBの学習データを処理する場合、従来の手順は: S3からEBSにダウンロード(数分かかる) データを処理する 結果をS3にアップロード EBSボリュームをクリーンアップ やりたい処理は2番だけです。S3 Filesでは、S3プレフィックスをマウントするだけで処理スクリプトはそのまま /mnt/s3files/ のファイルを読み書きします。ダウンロード・アップロード・クリーンアップのステップが消えます。 ...

2026年4月9日 · 4 分

Exbrain — Claude Code × Obsidian で「外付けAI脳」を構築する

チャエン(@masahirochaen)さんが「外付けのAI脳」と名付けたシステム Exbrain を GitHub で公開した。Claude Code × Obsidian × 常駐エージェントを組み合わせて、記憶・日報・クリッピングを全自動化するという意欲的なプロジェクトだ。 GitHub: chaenmasahiro0425/exbrain Exbrain とは Exbrain は「自分の外側にある AI の脳」を目指したパーソナル PKM(Personal Knowledge Management)システムだ。Karpathy が提唱した「LLM Wiki」パターンの実装版として設計されており、AIが継続的に自分の経験・価値観・目標を学習し続ける仕組みを提供する。 主な特徴: 毎朝の日報自動作成: AI がカレンダー・Slack・Gmail を読み込み、その日のブリーフィングを自動生成 毎夕の振り返り: AI が1日の行動を分析し、繰り返しパターン(例:「月曜は会議10件が3週連続」)を検出・記録 自動クリッピング: X でブックマークした記事やツイートを約4時間後に自動要約して Obsidian に蓄積 Slack 連携: Slack の DM に URL を投げるだけで即座にクリップ 常時稼働: PC を閉じた状態・就寝中でもエージェントが動き続ける iPhone で全部読める: Obsidian の同期により、モバイルからもアクセス可能 SOUL / MEMORY / DREAMS の3ファイル設計 Exbrain の核心は、自分自身を表現する3つの Markdown ファイルだ。 ファイル 役割 SOUL.md 自分は誰か(価値観・境界線) MEMORY.md 何を経験したか(決定・学び) DREAMS.md どこに向かうか(洞察・未解決の問い) AI はこの3ファイルを毎日読み込み、そのコンテキストをもとに振り返りや提案を行う。単なるメモ帳ではなく、AIが自分のことを「知っている」状態を維持する仕組みだ。 ...

2026年4月9日 · 2 分

関係人口とは?観光以上・移住未満の新しい地域との関わり方

「関係人口」という言葉を耳にする機会が増えています。移住でも観光でもない、地域との新しい関わり方を指す概念です。人口減少が進む日本の地方創生において、重要な鍵となっています。本記事では、関係人口の定義から最新の制度動向、成功事例、そして課題まで包括的に解説します。 関係人口とは 関係人口とは、移住した「定住人口」でもなく、観光に来た「交流人口」でもない、地域や地域の人々と多様に関わる人々のことです。よく「観光以上・移住未満」と表現されます。 具体的には、以下のような形で特定の地域と継続的に関わる人を指します。 副業・兼業で地方の仕事に携わる 祭りやイベントの運営に参加する ボランティア活動に定期的に参加する ふるさと納税を通じて地域を応援する 二拠点生活(デュアルライフ)を送る 3つの「人口」の違い 地域との関わりは、はっきりとした線引きではなくグラデーションになっています。 区分 定義 地域との結びつき 交流人口 通勤・通学・観光・レジャーなどで一時的に地域を訪れる人 弱い(一過性) 関係人口 居住地以外の特定の地域と継続的かつ多様に関わる人 中程度(継続的) 定住人口 地域に住居を構えて定住している人 強い(生活基盤) 関係人口は地域に何度も訪れるうちに親しみや思い入れが深まり、将来的な定住につながる可能性も秘めています。この「心の変化」を含めた段階的な関わりが、関係人口の本質的な特徴です。 なぜ関係人口が注目されるのか 地方が直面する課題 日本の地方圏は人口減少・高齢化により、地域づくりの担い手不足という深刻な課題に直面しています。定住人口の増加だけで解決することは現実的に難しい状況です。そこで、地域外の人材が「関わりしろ」(外部の人が参加できる余地)を持って地域づくりに参画する仕組みが求められています。 関係人口の規模 国土交通省が2025年6月に公表した調査によると、全国の18歳以上の居住者(約1億275万人)のうち、**約2,263万人(約22%)**が関係人口として特定の地域に継続的に関わっています。 訪問系関係人口: 約1,884万人(実際に地域を訪れて関わる) 非訪問系関係人口: 約379万人(オンラインや寄付などで関わる) 5人に1人以上が何らかの形で居住地以外の地域と関わっており、その裾野の広さがうかがえます。 ふるさと住民登録制度:関係人口を「見える化」する 地方創生2.0の目玉政策 2025年、政府は「地方創生2.0」の基本構想として、関係人口を可視化する「ふるさと住民登録制度」の創設を打ち出しました。これは2025年度から2034年度までの10年間の方向性を示す政策の柱の一つです。 制度の仕組み ふるさと住民登録制度は、居住地以外の地域と継続的に関わる人をスマートフォンアプリで「ふるさと住民」として登録する仕組みです。 マイナンバーを活用し、アプリで登録を申請 自治体が登録証を発行 登録は関わり方に応じて2種類に分類 登録タイプ 対象 関わり方の例 ベーシック登録(仮称) 気軽に地域と接点を持つ人 特産品の購入、ふるさと納税 プレミアム登録(仮称) 地域活動の担い手になる人 ボランティア、副業・兼業 政府は10年後に1,000万人のふるさと住民登録者を目標としています。 成功事例 海士町(島根県):LINEミニアプリ「miniama」 離島の海士町は、島での体験を「ミッション」として楽しめるLINEミニアプリ「miniama(みにあま)」を2025年に開発しました。公開から3ヶ月で登録者が1万人を突破。デジタル技術を活用した関係人口創出の好例です。 みなべ町(和歌山県):梅収穫ワーケーション 特産の梅の収穫時期の人手不足を解消するため「梅収穫ワーケーション(梅ワー)」を実施。リモートワーカーが農作業を手伝いながら滞在し、人手不足の解消と関係人口の増加を同時に達成しました。 美濃市(岐阜県):古民家再生事業 美濃市と十六銀行が共同出資した「みのまちや」が中心となり、歴史的な古民家の再生と地域課題の解決に取り組んでいます。この取り組みにより、美濃市の宿泊者数が過去最高を記録しました。 ひたちなか市(茨城県):学生向けインターン 若者と地域のつながりを広げ、将来的な移住・定住につなげる「ひたちなかBRIDGEプロジェクト」を2022年度から継続実施。学生インターンを通じた関係人口の創出に取り組んでいます。 SMOUT:関係人口マッチングプラットフォーム 面白法人カヤックが運営する「SMOUT」は、移住・関係人口促進のためのマッチングプラットフォームです。 2018年6月にサービス開始 1,089地域が登録(2024年12月時点) 約6.4万人のユーザーが利用 「ネット関係人口スコア」でオンライン上の関わりを可視化 地域側は「仲間を集めたい」「移住者を募りたい」というニーズを発信し、一般ユーザーは興味のある地域にアプローチできる仕組みです。データを活用した移住施策の検討にも役立てられています。 ビジネスへの応用:ファンマーケティングとの共通構造 関係人口の概念は地方創生の文脈で生まれましたが、その構造は企業のファンマーケティングと驚くほど共通しています。地域をブランドに、訪問者を顧客に読み替えれば、関係人口の創出プロセスはそのまま顧客エンゲージメント戦略になります。 ...

2026年4月9日 · 1 分

giftee(ギフティ):eギフトプラットフォームで「キモチの循環」を実現する企業の全貌

株式会社ギフティ(証券コード: 4449)は、eギフトの発券から流通・販売までを一気通貫で提供する「eギフトプラットフォーム事業」を展開する企業です。個人向けカジュアルギフトから法人ソリューション、自治体向けプラットフォームまで、多角的なサービスを通じてデジタルギフト市場をリードしています。 会社概要 項目 内容 社名 株式会社ギフティ(Giftee Inc.) 設立 2010年8月10日 代表取締役 太田 睦、鈴木 達哉 本社 東京都品川区東五反田2-10-2 東五反田スクエア12階 上場市場 東京証券取引所プライム市場(証券コード: 4449) ミッション・ビジョン ギフティは創業10周年を機にミッションとステートメントを刷新しています。 コーポレート・ミッション: 「キモチの循環を促進することで、よりよい関係でつながった社会をつくる」 コーポレート・ビジョン: 「eギフトを軸として、人、企業、街の間に、さまざまな縁を育むサービスを提供する」 単なるギフトの電子化にとどまらず、「キモチ」という感情的価値をデジタルで循環させるという大きな構想が根底にあります。 主要サービス giftee(個人向けカジュアルギフト) メールやLINE、SNSを介して、住所を知らない相手にも気軽にギフトを贈れるサービスです。「ありがとう」「おめでとう」といった日常の感謝や祝いを、数百円〜の手軽な価格帯でギフトとして届けることができます。2025年12月末時点で会員数は253万人に達しています。 代表的な利用例として、スターバックスの「ドリンクチケット(500円)」があります。2014年の取り扱い開始以来、LINEやメールでスタバのドリンクを気軽に贈れる手段として定着しており、受け取った人は店頭でバーコードを提示するだけで好きなドリンクと交換できます。 giftee for Business(法人向けソリューション) eギフトを活用した法人向けソリューションです。キャンペーンの景品や顧客への謝礼として、コンビニ商品やコーヒーなどのギフトをLINEやメールで簡単に送付できます。2025年12月末時点で累計導入案件数は75,000件を突破し、導入企業は1,000社を超えています。日本生命保険相互会社、コーエーテクモゲームスなどの大手企業から、日進市・武蔵野市といった自治体まで、幅広い業種・組織で導入されています。 eGift System(eギフト発券・流通システム) 店頭引換可能なeギフトの生成と、生成したeギフトを自社サイト上で販売するためのシステムです。コンテンツプロバイダー(ギフト発行元)は270社以上に到達しており、スターバックスや大手カフェチェーンから、ホテル・アパレルまで多様な業種に拡大しています。 STUDIO GIFTEE(ギフト体験設計) 企業と顧客・従業員、自治体と住民とのよりよい関係づくりのために、ギフト体験を企画・設計する専門チームです。 e街プラットフォーム(自治体・地域向け) 地域の課題を解決し活性化するためのデジタルプラットフォームです。スマートシティやIoT対応で「人と街」をつなぎ、自治体のデジタル化推進を支援します。 ビジネスモデルの強み 一気通貫のプラットフォーム ギフティの最大の強みは、eギフトの「発券」「流通」「販売」をすべて自社プラットフォーム内で完結できる点です。コンテンツプロバイダーが発行したeギフトは、API連携を通じて個人向け「giftee」、法人向け「giftee for Business」、自治体向け「e街プラットフォーム」の各チャネルで販売されます。 ストック型ビジネスモデル 一度導入した企業・自治体がリピート利用するストック型の収益構造を持っています。2024年度のプラットフォーム流通額は年間1,000億円規模に達し、高い成長率を維持しています。 拡大するeギフト市場 国内eギフト市場は2020年の2,075億円から2025年には4,057億円へと拡大が見込まれています。ギフティはこの成長市場において主要プレイヤーの一つとなっています。 最新動向(2026年) giftee Benefit(福利厚生プラットフォーム) 2026年4月には福利厚生のプログラム基盤「giftee Benefit」をナレルグループに提供し、従業員約4,000名規模での導入が発表されました。eギフトの活用領域を福利厚生分野にも広げています。 セルフギフト市場への展開 従来の「他者に贈る」ギフトだけでなく、自分へのご褒美としての「セルフギフト」市場にも注力しています。2026年度は数億円規模の流通額を見込んでいます。 eギフト商品ラインナップの拡充 2025年10月〜12月の期間だけで26ブランド90種類の商品をeギフト化し、選択肢の多様化を進めています。 まとめ ギフティは「eギフト」という一つの軸から、個人・法人・自治体という3つの顧客セグメントに対して、それぞれ最適化されたサービスを展開しています。「キモチの循環を促進する」というミッションのもと、デジタルギフト市場の拡大とともに成長を続ける注目のプラットフォーム企業です。 参考リンク 株式会社ギフティ 公式サイト giftee(カジュアルギフトサービス) giftee for Business 事業紹介 - 株式会社ギフティ

2026年4月8日 · 1 分

MONOCO(モノコ):「使い惚れ」だけを届けるキュレーションECの実力

「お買い物に、“ストーリー"を。」——MONOCO(モノコ)は、スタッフが3週間以上実際に使い込んで「使い惚れ」した商品だけを販売する、キュレーション型ECサイトです。大手ECとは一線を画すそのビジネスモデルと、創業からの歩みを紹介します。 MONOCOとは MONOCO は、株式会社MONOCOが運営するオンラインセレクトショップです。インテリア、家電、ファッション、寝具、キッチン用品、健康・美容、食料品など幅広いカテゴリの商品を取り扱っています。 最大の特徴は独自の品質基準。バイヤーが商品を3週間以上実際に使用し、心から満足した「使い惚れ」アイテムだけをセレクトして販売しています。会員数は29万人を超え、300以上のブランドを取り扱っています。 サービスの特色 ストーリーテリングによる商品紹介 MONOCOの商品ページは、単なるスペック表示ではありません。商品の魅力を「ストーリー」として伝えるコンテンツ型の構成になっています。大きな商品画像に独自のキャッチコピーを添え、使用シーンや開発背景まで丁寧に紹介しています。 キュレーションモデル 大手ECのように膨大な商品を並べるのではなく、厳選された商品だけを掲載するキュレーション型を採用しています。「数あるモノから選び抜き、ココロ動く体験を届ける」というコンセプトのもと、量より質を重視した品揃えが特徴です。 ブランディング・PR一体型プラットフォーム MONOCOは単なる販売チャネルではなく、ブランディング・PR・セールスプロモーション・販売が同時にできるプラットフォームとして機能しています。メーカーのパートナーとして、商品の価値を再発見・再発信する役割も担っています。 便利な機能 シーンベース検索: GIFTS、HEALTHY、HOME、WORK、ENJOYなど、利用シーンから商品を探せる 価格帯別検索: 1,000円未満〜30,000円以上まで、予算に合わせて絞り込み可能 法人ギフト対応: 企業の贈答品ニーズにも対応 ギフトラッピング: プレゼント用のラッピングサービスあり 月間TOP30ランキング: 人気商品がひと目でわかる アウトレットセクション: お得に購入できるコーナーも用意 運営会社と創業ストーリー 会社概要 項目 内容 会社名 株式会社MONOCO(MONOCO, Inc.) 設立 2012年4月 代表取締役社長 柿山 丈博 所在地 東京都港区南青山五丁目17番2号 事業内容 EC事業、ブランディング・PR、セールスプロモーション企画、ブランド企画販売 関連会社 株式会社VONDS(ランドセルブランド事業) 再起の物語 MONOCOの歩みは順風満帆ではありませんでした。2010年に大学在学中のプロジェクトとしてスタートし、2012年にフラッシュセール(期間限定の特売)形式でECサイトを立ち上げました。 しかし2014年11月、共同創業者による資金横領が発覚し、億単位の債務を抱える経営危機に陥りました。社員全員の解雇を余儀なくされるという壮絶な事態でした。 代表の柿山氏は妻と2人の協力者とともに、2015年1月1日に会社を再スタート。そこから現在の「ストーリーでお買い物を楽しむ」というコンセプトを確立し、29万人の会員を擁するサービスへと成長させました。 ビジョン:「たからものでいっぱいの人生」 MONOCOが掲げるビジョンは「たからものでいっぱいの人生」。ここでいう「たからもの」とは、物質的な商品だけでなく、家族、仲間、思い出、趣味など、人生を豊かにするあらゆる要素を指しています。 資金調達と投資家の変遷 MONOCOは創業以来、累計約6.1億円(約611万ドル)を15社の投資家から調達しています。 時期 ラウンド 投資家 概要 2011年8月 Seed サイバーエージェント・キャピタル 最初の外部資金調達 2013年7月 Series A KDDI Open Innovation Fund(運用: Global Brain) 数億円規模。「au Brand Garden」出店、表参道ショールーム開設へ 2013年9月 追加出資 フジ・スタートアップ・ベンチャーズ(フジ・メディアHD子会社) フジテレビ番組とのコラボ・オリジナル商品開発を構想 2018年11月 Corporate 三陽商会 発行済株式の16%を取得、取締役1名を派遣 このほか、ABC Dream Ventures(朝日放送グループHD系)やデジタルガレージなども出資しています。 ...

2026年4月8日 · 1 分

オープンロジ(OPENLOGI)とは — 固定費ゼロの物流フルフィルメントプラットフォーム

EC事業を運営するうえで、物流は避けて通れない課題だ。商品の入荷、保管、梱包、出荷、返品対応 — これらを自社で回すのは人的コストが大きい。オープンロジ(OPENLOGI) は、こうした物流業務をまるごとアウトソーシングできるプラットフォームとして、13,000社以上に導入されている。 オープンロジの概要 オープンロジは、株式会社オープンロジが運営するEC向け物流フルフィルメントサービスだ。 項目 内容 運営会社 株式会社オープンロジ 代表 伊藤 秀嗣(代表取締役社長CEO) 設立 2013年12月 所在地 東京都豊島区東池袋 導入数 約13,000アカウント(2024年1月末時点) 倉庫拠点 全国70拠点以上 ビジョン オープンロジが掲げるビジョンは明確だ。 テクノロジーを使い、サイロ化された物流をネットワーク化し、データを起点にモノの流れを革新する 従来の物流業界では、倉庫ごとにシステムが分断され、FAXや電話でのやり取りが当たり前だった。オープンロジは独自の倉庫管理システム(WMS: Warehouse Management System)で全国の倉庫をネットワーク化し、EC事業者がオンラインで物流業務を完結できる環境を構築している。 サービスの特徴 1. 固定費ゼロの従量課金制 オープンロジ最大の特徴は初期費用・月額固定費がかからないこと。料金は以下の3要素の従量課金で構成される。 入荷料: 商品を倉庫に送り入れる際の費用 保管費: 倉庫で商品を保管する期間に応じた費用 配送料金: 出荷時の費用 使った分だけ支払う従量課金のため、季節変動が大きいEC事業でも無駄なコストが発生しない。小規模事業者やスタートアップが物流を外部化する際のハードルが低い。 2. API連携による自動化 オープンロジの技術的な強みはAPI連携の充実度だ。以下のプラットフォームと連携し、受注から出荷までを自動化できる。 ECプラットフォーム: Shopify、STORES、BASE、ecforce、makeshop ECモール: 楽天市場、Yahoo!ショッピング、TikTok Shop、Qoo10 受注管理: ネクストエンジン、GoQSystem 自社システム: 公開APIによるカスタム連携 API連携による自動出荷率は93.5%以上を達成しており、注文の大半は人手を介さず自動で出荷指示まで完了する。 3. フルフィルメントネットワーク 全国70拠点以上の倉庫ネットワークにより、事業の成長に合わせて柔軟にスケールできる。 物量の急増(セール、季節需要)に対応可能 配送先に近い倉庫からの出荷でリードタイム短縮 倉庫業務のシステム化により高品質・ミスのない配送を実現 4. カスタマイズ可能な梱包 ユーザーごとにカスタマイズ可能な梱包指示に対応している。ブランドイメージに合わせた梱包材やチラシの同梱など、EC事業者の要望に応じた柔軟な対応が可能だ。 5. BPOサービス(カスタマーサポート代行) 2025年からは固定費ゼロ・従量課金でカスタマーサポート代行(BPO: Business Process Outsourcing)サービスも提供している。物流だけでなく、顧客対応までワンストップで外部化できる。 他の物流代行サービスとの違い オープンロジが従来の倉庫会社と異なる点は次の5つだ。 API連携で業務を自動化 — FAXやメールではなく、システム連携が前提 従量課金 — 最低契約数量や月額固定費がない 国内・海外配送にワンストップ対応 — 越境ECにも対応 独自の倉庫ネットワーク — 単一倉庫ではなく、全国拠点から最適配送 アナログやり取り不要 — すべてオンラインで完結 どんな事業者に向いているか スタートアップ・小規模EC: 固定費ゼロで始められるため、初期投資を抑えたい事業者 急成長中のEC: 70拠点のネットワークでスケールに対応 Shopifyユーザー: Shopify連携が充実しており、自動出荷の仕組みを構築しやすい 越境EC: 海外配送にも対応しているため、海外販売を視野に入れた事業者 まとめ オープンロジは「物流のことは物流のプロに任せて、事業者は商品企画と販売に集中する」という考え方を技術で実現したプラットフォームだ。固定費ゼロの従量課金、93.5%以上の自動出荷率、全国70拠点の倉庫ネットワークという3つの柱で、EC事業者の物流課題を解決している。 ...

2026年4月8日 · 1 分

Claude Code にカオスエンジニアリングエージェントを導入してリポジトリの弱点を発見する

Claude Code のカスタムエージェント機能を使って「カオスエンジニア」を導入すると、リポジトリの潜在的な弱点を自動的に発見できる。.md ファイルを1つ置くだけで有効化でき、驚くほど多くの問題が見つかることで話題になっている。 カオスエンジニアリングとは カオスエンジニアリングは、本番システムに意図的に障害を注入してシステムの耐障害性を検証する手法だ。Netflix が提唱した概念で、Chaos Monkey のような自動障害注入ツールが知られている。 Claude Code にカオスエンジニアリングの思考を持ったエージェントを持ち込むと、コードベースに対して「もし〇〇が壊れたら?」という視点で弱点分析を行ってくれる。 導入方法 Claude Code のカスタムエージェントは .claude/agents/ ディレクトリに .md ファイルを置くだけで使える。 以下が chaos-engineer エージェントの定義例だ: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 # chaos-engineer あなたはカオスエンジニアリングの専門家です。 システムに意図的に障害を起こす視点でリポジトリを分析し、 潜在的な弱点・単一障害点・エラーハンドリングの欠如を特定してください。 ## 分析観点 - 単一障害点(SPOF)の特定 - エラーハンドリングの欠如箇所 - タイムアウト設定の不備 - リトライ処理の欠如 - 環境変数・設定値のハードコーディング - 依存サービスがダウンした場合の挙動 - データ整合性が保証されない処理 - テストカバレッジが低い重要処理 ## 出力形式 各問題について以下を明記する: - 問題箇所(ファイルパス・行番号) - 障害シナリオ - 影響範囲 - 推奨する対策 このファイルを .claude/agents/chaos-engineer.md として保存する。 ...

2026年4月7日 · 2 分