Posts

Power Automate も Power Apps も Azure Logic Apps も、Dataverse に対しては同じ Web API を叩いている。 「このツールではできない」と止まるとき、問題は API に届いていないことではなく、そのコネクタが必要な機能を露出しているかどうかに 9 割ある。 壁の正体を理解すれば、問い直すべき場所が変わる。 全ツールが同じ API に届いているDataverse の入口は、すべてのツールで共通だ。Power Automate のコネクタも、Power Apps のフォームも、Azure Logic Apps のアクションも、最終的には Dataverse Web API（OData v4 実装） を経由してサーバーと通信する。 この構造は公式ドキュメントで裏付けられている。Dataverse Web API は「Organization service のすべてのメッセージを functions/actions として露出している」（Microsoft Learn: Web API types and operations, 2025 年時点）。コードで直接 Web API を呼べば、サーバーが持つ全操作にアクセスできる。 コネクタの内部も同様だ。「Connectors create a proxy or wrapper around an API that allows the underlying App Service Environment to talk to Microsoft Power Automate, Power Apps, Azure Logic Apps and Power BI」（dev.to/wyattdave: The 4 APIs of the Power Platform）。コネクタは直接の接続ではなく、Azure APIM（API Management）を経由した OpenAPI ラッパーとして機能する。すべてのコネクタホストは、この APIM 経由で同一の Dataverse バックエンドに到達している。 ...

Dataverse への取込ツールは、好みや習熟度で選ぶと後で詰まる。 判断軸は 2 つだけ——代替キーで Lookup を解決できるか、secretless Managed Identity（MI）で繋げるか。 この 2 軸を両方満たすツールは、2026 年 6 月時点で Azure Functions（SDK for .NET）と Azure Data Factory（ADF）に限られる。 2 軸で絞る——なぜ「Lookup 解決力 × MI secretless」なのかDataverse の行レベルセキュリティ（Row-level Security）は、レコードの「所有者（owner）」フィールドを起点に動く。 この所有者は、取込レコードに Lookup 列（参照列）が正しくセットされているとき、初めて自動設定が発火する。 つまり、取込ツールが Lookup 列を解決できなければ、所有者は設定されず、行セキュリティはそもそも機能しない。 認証が Managed Identity（secretless）でない場合は、シークレット管理の運用負荷と漏洩リスクが別途発生する。 2 軸を分けて評価しても意味が薄い。取込ツールの選定は、この 2 軸の同時達成で決まる。 ツール能力マトリクス環境前提：Dataverse への書き込み、代替キー（Alternate Key）によるインライン Lookup 解決、secretless MI 認証の 3 要件で評価する（2026 年 6 月時点）。 ツール 代替キー Lookup 解決 MI secretless 接続 両軸評価 Power Automate（Dataverse コネクター） △ 行操作は可、複雑な Lookup 解決は制限あり △ SP + Secret は対応済み。secretless MI は標準コネクターでは未対応。HTTP / Custom Connector 経由で実現可能だが設計コスト増 △ Power Apps Dataflows（Power Query ベース） △ 代替キー設定済みテーブルなら解決可 △ 公式ドキュメントに MI 接続手順の記載なし（2026 年 6 月時点）。SP + Secret が一部利用可 △ Azure Functions（SDK for .NET） ✓ EntityReference + 代替キーで GUID 不要 ✓ ManagedIdentityCredential で secretless 対応 ✓ Azure Data Factory（ADF） ✓ Lookup Activity 等で対応 ✓ MI 対応コネクター ✓ 注意：Azure Data Factory の Mapping Dataflows は MI 接続に対応しているが、Power Platform の Power Apps Dataflows とは別製品。Power Apps Dataflows（Power Query ベース）と ADF Dataflows を同一視しないこと。 ...

顧客の開発案件を受けていれば、一度は似た場面に出くわしているはずだ。 「個人PCでの開発はセキュリティ上NGです」。「本番データをそのまま使わないと動作確認できません」。「弊社の開発環境に入ってもらわないと進めようがありません」。 こちらとしては、本番データを一切受け取らず、構造（スキーマや設計ファイル）だけを外に出してもらい、成果物をファイルで納品する方が、データ漏洩のリスクは構造的に低い——と説明する。だが、話が通りにくい。賛同の声もほとんど届いてこない。 「外から内へ」という設計は、技術的には成立している。ISO/IEC 27002:2022のControl 8.33は「合成データを本番データよりも優先して使用すること」を明示しており、日本でも経産省が令和7年改正版の情報セキュリティ管理基準でこれを引用している。個人情報保護法第25条の委託先監督義務も、本番データを外に出さない設計であれば根本から負担が消える。制度的にも技術的にも、筋は通っている。 それでも公の声が上がらない。なぜか。 安心感と安全は、同じではないセキュリティ研究者のBruce Schneierは2003年の著書『Beyond Fear』の中で、「security theater（保安劇場）」という概念を定義した。「安全を実質的に向上させることなく、より安全と感じさせるセキュリティ対策」のことだ。Schneierは後年のブログでも補足している——「security theaterが完全に無意味だとは言っていない。愚かな攻撃者を追い払う効果はある。だが、形式的な安心感と実質的な安全改善は、別物として理解する必要がある」と。 日本の企業セキュリティによく見られる「持込PC禁止」「入館時に誓約書」「外部委託先に本番データコピーを渡してアクセス管理」という形式は、この視点で見ると興味深い位置に立つ。 本番データへのアクセス経路を構造的に絶つのではなく、「誰がどの端末で触るか」という人・機器の管理で安心感を作っている。委託先に本番データを渡しながら、渡した後の取り扱いを誓約書で縛る。これは「データを外に出さない」設計ではなく、「出した後のリスクを証書で管理する」設計だ。 形式的な安全と実質的な安全の混同——Schneierの言葉を借りれば、これがsecurity theaterの構造に近い。禁止系のルールが全く無意味だと言いたいわけではない。ただ、「見た目で勝つが実質で負ける」と「実質で勝つが見た目で負ける」の二択を迫られたとき、どちらが選ばれやすいかは、もう少し考える必要がある。 なぜ採用を罰する構造になっているのか「外から内へ」の設計を採用しようとした方針決定者を想像してみてほしい。 もし本番データが漏洩したとき、その決定者は責任を問われる。採用前のやり方と違うことを選んだ判断として、批判の的になる。一方で、設計が機能してデータ漏洩が「起きなかった」場合、その成果は目に見えない。ゼロのままだ。生産性が上がっても、その恩恵は現場エンジニアか事業部門が受け取り、方針決定者のパフォーマンス評価には反映されにくい。 下振れリスクは決定者が個人で負い、上振れの果実は組織に拡散する——こうした誘因の非対称があるとすれば、「前例のないやり方を採用しない」という判断は、個人として合理的だ。構造的に推測できる話として、公の賛成表明が出にくいのはここに原因の一端があると見ている。 加えて、セキュリティ業界そのものの経済構造も関係している。本番データへのアクセス管理・暗号化・通信監視といったソリューションは、「本番データが外に出ることを前提とした上で、どう守るか」というモデルで設計されている。「そもそも本番データを外に出さない」設計が普及すると、このモデルの一部は需要を失う。逆説的だが、「本番データを出さない」方向の需要は急速に膨らんでいる。合成テストデータの市場規模は2024年時点で18億ドル超、2029年には82億ドルへの成長が予測されており（GlobeNewsWire, 2026年1月）、NVIDIAが合成データスタートアップのGretel.aiを2025年3月に買収したことも、その潮目を示している。技術の方向性は変わりつつある。制度的な慣性が、そこへの移行を遅らせている。 多重下請けの構造が、ファイル一個を拒む日本で特にこの設計が普及しにくい理由が、もう一層ある。 公正取引委員会が2022年6月に発表した「ソフトウェア業の下請取引等に関する実態調査報告書」は、約4,700社の回答と大手・中堅ITベンダー16社へのヒアリングに基づく調査だ。この報告書は、ソフトウェア開発業務において4次下請け・準委任契約（SES）で最大5社が中間に入るケースを確認している。エンドユーザーへの質問が途中の業者で止まる、メール連絡がたらい回しになる——こうした実態が記録されている。 この構造の中で、「個人が構造ファイル1個を直接顧客に納品する」というモデルはどうなるか。中間に入るベンダーにとって、それは自社の存在意義を問い直す話になる。人月で工数を積み上げ、複数社が中間で利益を抜く商習慣は、「一人がファイル1個を直接届ける」モデルとは利益構造として相性が悪い。 啓蒙や説明では動かないのは、ここに理由がある。情報が届いていないのではない。構造が動くことへのインセンティブが、関係する多くのプレイヤーに存在していないのだ。 技術が先行し、制度が追いつかない一方で、開発の技術環境は別のスピードで変わっている。 元OpenAIのAndrej Karpathyが「vibe coding」という言葉をXに投稿したのは2025年2月のことで、「自然言語で開発の意図を渡し、コードの存在を忘れる」という開発スタイルを描いたその投稿は4,500万回以上閲覧された。彼は同年6月のYCombinator講演でも「自然言語が新しいプログラミングインターフェース」になるというパラダイムを論じた。ソロ開発者のPieter Levelsは月収25万ドル超のポートフォリオを一人で運営し、Sam Altmanは「AIなしでは不可能だった一人で10億ドル企業が生まれる」という予測を2024年に語っている。 技術的な可能性は急速に現実に近づいている。「外から内へ」設計——本番データを受け取らず、構造だけを持ち出し、成果物をファイルで納品する——はそのモデルと親和性が高い。障壁は技術にない。制度的な誘因と慣行の慣性にある。 律速は理解ではなく前例だでは、どう動くか。 「正しいと思うなら声を上げればいい」という話ではない。構造を前にして個人が声を上げても、現状の誘因構造では個人が批判のリスクを引き受けるだけになる可能性が高い。 有効なのは、小さく実証し、前例を作ることだ。「見た目の安全」チェックも通る形で実装する——別名スキーマで設計し、納品前の出庫スクラブ（本番識別子の除去確認）を記録に残し、完了後の削除証明を添える。ISO 27002:2022 Control 8.33が要求する「別途承認手続き・監査証跡」の仕組みは、まさにこの見た目の安全チェックと重ねて使える。 制度的チェックをクリアした上で、実質的な安全も確保する——その組み合わせの前例が積み上がったとき、慣行は動く。 Schneierの言葉を引き返せば、安心感と安全は同じではない。だが、動き出すためには安心感も必要だ。実質だけを主張して動かないより、見た目のチェックも添えて前例を一つ作る方が、律速は早く解除される。 今週末の1時間：自分が関わっている案件で「本番データを受け取らなくても設計できる部分」を一つ特定してみる。スキーマだけ外に出して構造を組む試作を、個人PC上で動かしてみる。前例は説明から生まれるのではなく、動いた実績から生まれる。 関連記事：顧客環境に拘束された時間は、あなたの資産にならない——「外から内へ」設計の実務戦略版 関連記事：開発環境への本番データ持ち込み、氏名マスク済みで安全と言い切れるか——本番データ識別子設計の技術版 関連記事：AIを使った成果物納品、キーもPIIも渡さない設計——build/bindの実務 how

Dataverse のレコードに所有者を設定するとき、「Owner」「Owning User」「Owning Team」「Owning Business Unit」の4欄が並んでいる。 どれを書けばいいか迷ったなら、答えは単純だ。書くのは Owner だけ。残り3つはプラットフォームが自動で埋める。 4欄すべてを手で触ろうとすると、途中でエラーか混乱のどちらかに当たる。 4欄あるが、手を出すのは1欄だけ4欄の役割を整理すると、こうなる。 欄名 役割 書き込み可否 Owner（OwnerId） 所有者の本体。ユーザーまたはチームの ID を指定する 書き込み可 Owning User（owninguser） Owner がユーザーの場合に自動設定される投影 読み取り専用 Owning Team（owningteam） Owner がチームの場合に自動設定される投影 読み取り専用 Owning Business Unit（owningbusinessunit） Owner が属する部署が自動設定される投影 読み取り専用 残り3欄が「読み取り専用」というのは、UI の見た目の話ではない。Microsoft のエンティティ定義レベルで IsValidForCreate: false かつ IsValidForUpdate: false が設定されており、作成・更新操作でこれらの列に値を渡してもプラットフォームが受け付けない（Account table/entity reference — Microsoft Learn）。 自動派生の連動は次のとおり動く（Security concepts in Microsoft Dataverse — Microsoft Learn）： Owner にユーザーを設定 → owninguser が自動更新、owningteam は null にリセット、owningbusinessunit はそのユーザーの部署に自動設定 Owner にチームを設定 → owningteam が自動更新、owninguser は null にリセット、owningbusinessunit はそのチームの部署に自動設定 Owner 1欄を正しく書けば、残り3欄は連動して正しくなる。逆に、残り3欄を直接操作しようとしても何も起きない。 ...

「持ち主を設定したのに課長から見えない」「チームを作るべきか、作らなくていいのか」——この判断がぶれるのは、owner（誰の責任か）と owningBU（どこに属すか）を1本の概念として扱うからだ。 2語に分けるだけで、Dataverse のアクセス制御設計は自分の言葉で説明できるようになる。 そして、純粋な階層要件であれば、チームは必要ない。 owner は名札、owningBU は番地——2語の役割を分けて定義するDataverse の行レベルアクセスは、2つの独立したフィールドで動いている。 **owner（名札）**は「このレコードは誰の責任か」を指す。設定できるのは1人のユーザーか1つのチームだけだ。 **owningBU（番地）**は「このレコードはどこに属すか」を指す。owning business unit（所有ビジネスユニット）の略で、常に1つのBU（ビジネスユニット：組織の管理単位。課・部・事業部などに対応させる）に紐づく。 Microsoft Learn「Security concepts in Microsoft Dataverse」（2026年時点）は次のように明示している。 “Data access to records is granted based on the owning business unit.” — Microsoft Learn: Security concepts in Microsoft Dataverse アクセスの開口部を決めるのは owningBU であり、owner ではない。ここが混同の出発点だ。 名札（owner）は「誰のものか」という属人的な指し示しであり、番地（owningBU）は「どのBU配下に置かれているか」という場所の指定だ。この2語は別のフィールドとして独立して存在し、別の経路でアクセス評価に効く。 2軸の効き先が違う——名札は本人経路で、番地は階層経路で効く名札（owner）が効くのは「本人経路」だ。ユーザーが自分自身のsystemuserid（Dataverse内部のユーザーID）と、レコードのownerIdフィールドを突き合わせることでアクセスが成立する。User深度のセキュリティロールがあれば、自分が名札に入っているレコードは見える。 番地（owningBU）が効くのは「階層経路」だ。レコードのowningBUと、アクセスしようとするユーザーのBU位置関係を評価する。セキュリティロールの深度設定がBU以上であれば、owningBUの属するBU内のレコードが見えるようになる。 この2つの評価経路は独立して動く。だから「持ち主が1人（name=担当者）なのに、課長からも見える」という状態が成立する。名札経路は本人しか通らないが、番地経路はBU階層を通して開口部を開けるからだ。 Microsoft Learn「How access to a record is determined」は、チーム所有経路について次のように記述している。 “In both cases, any access level will suffice to have access regardless of the business unit the record belongs to.” — Microsoft Learn: How access to a record is determined ...

「担当者ごとに見え方を変えたい」という要件が来たとき、最初にフィルター条件を書き始めると詰まる。 Dataverse は毎クエリ、ログイン時のトークン情報から「あなた」に対応する内部ユーザーを自動で特定し、レコードの持ち主と突き合わせて表示範囲を決める。 作り手がやるべき準備は、ログインする人とレコードの持ち主を正しく結びつけることだけだ。 3つのIDを整理するDataverse の担当者管理を理解するには、3種類のIDを別物として扱う必要がある。 1. ログインID（Azure AD Object ID） Entra ID（旧称 Azure Active Directory）がログイントークンに乗せる識別子。azureactivedirectoryobjectid という列名で Dataverse の内部に保持される。ユーザーがアプリを開いた瞬間、このIDがトークンの中に含まれている。 2. 内部ユーザーID（systemuserid） Dataverse 環境内部で割り当てられるGUID（グローバル一意識別子）。レコードの ownerid（所有者）欄に実際に入るのはこのIDだ。外部システムには存在しない、Dataverse 固有の識別子になる。 3. 職場アカウント（UPN / domainname） [email protected] 形式の文字列。Dataverse では domainname 列として保持される。人間が読める識別子だが、文字列なのでそのままでは Lookup（関連テーブルへの参照）として機能しない。 この3つを混同して設計すると、データ取込時に ownerid がnullになったり、フィルターを書いても動かない状態が発生する。 利用者登録が3つのIDを橋渡しする3つのIDをつなぐ場所は1か所だけ、systemuser（SystemUser テーブル）だ。 Microsoft Learn のシステムユーザーテーブル定義（2024年–2026年）によると、このテーブルの1レコードには次の3列が同居している。 列名 内容 systemuserid Dataverse 内部の GUID（主キー） azureactivedirectoryobjectid Entra ID から同期されたログインID domainname UPN（[email protected] 形式） M365 管理センターや Entra ID との同期で利用者を登録すると、この1レコードに3つのIDが書き込まれる。橋は1か所だけで完結する。逆に言えば、この連携が成立していないと——たとえばユーザーが未登録だったり、UPNが変更されて不一致になっていたりすると——後続のすべての処理が機能しない。 毎クエリ自動で突き合わせる（フィルターを書かない）Power Apps のモデル駆動型アプリや Dataverse Web API にリクエストが来るたびに、Dataverse サーバーは次の処理を自動で実行する。 トークンの azureactivedirectoryobjectid → systemuser テーブルの azureactivedirectoryobjectid 列で照合 → systemuserid（内部 GUID）を解決 → レコードの ownerid と突き合わせ → 行レベルセキュリティを評価 セキュリティロールの深度が「User（Basic）」に設定されている場合、ownerid がログインユーザーの systemuserid と一致するレコードだけが返却される。この評価は画面・API・Power Automate のすべてに共通して適用される（Microsoft Learn「Security concepts in Microsoft Dataverse」）。 ...

基幹から来る支社コード・課コードは、テキストのまま流せば取り込みは通る。だが、後で階層クエリや集計に使おうとして詰まる。取り込みながら Lookup 関係へ変換する——その判断を先送りにすると、後工程のコストになって返ってくる。 結論から言う。代替キー（Alternate Key）を使えば、内部 GUID なしに Lookup を張れる。 親→子の順序を守り、「変換ジョブが緑（成功）」と「関係が張れた」を別物として確認する。この 3 点で、横長テキストコードは取込時に関係データに変わる。 コードと関係は別物——なぜ後回しにすると詰まるかDataverse に支社コード「A001」を文字列として格納しても、その行は「支社テーブルの A001 レコード」を参照していない。文字列の一致と Lookup 関係は別物だ。 文字列のままでは、Dataverse のリレーションシップ機能（階層ナビゲーション・関連レコード展開・ロールアップ集計）が一切使えない。基幹から来る横長コードを「いったんコードのまま流す」設計は、後で Lookup を張り直す移行コストとセットになる。 Microsoft 公式は代替キーを「外部システムとの統合で GUID を保持していない場合に一意識別する仕組み」として定義している（Define alternate keys to reference rows）。つまり、内部 GUID を知らなくても業務コードで関係を張る経路は、公式に用意されている。 代替キーで Lookup を張る——前提条件と実装の骨格代替キーとはDataverse のテーブルは、行を一意に識別する主キーとして内部 GUID を持つ。代替キー（Alternate Key）は、業務コード等の外部識別子を GUID と等価な参照先として登録する仕組みだ。代替キーを定義した列は、Lookup を張る際の解決キーとして使える。 前提条件 3 点1. 参照先テーブルに代替キーを定義する Dataflow のマッピング画面で Lookup フィールドが選択できない場合、参照先テーブルに代替キーが未定義であることがほとんどだ。まず親テーブル（支社テーブル、課テーブル等）に対して代替キーを追加し、Dataflow のマッピングを再設定する（Field mapping considerations for standard dataflows）。 2. 代替キーの型は Text 型または Number 型のみ Dataflow マッピングで利用できる代替キーの型は Text 型または Number 型に限られる。日付型・選択肢型等を代替キーとして定義している場合、Dataflow マッピングでエラーになる。業務コードが日付型フィールドで管理されている場合は Text 型で定義し直す（Field mapping considerations for standard dataflows、コミュニティ報告: Fabric Community）。 ...

フォームから列を外しても、その列は API・エクスポート・レポートから普通に読める。 列の機密を守るのはフィールドセキュリティプロファイル（列ごとに「許可した身分だけ可視」と設定するプロファイル）の仕事であり、フォーム編集とは別のレイヤーで動く。 「行は読めるのに、その列だけ null が返る」という状態を設定後に API で確認するまでが、設計の完了だ。 「フォームから外す」と「列を隠す」は別の操作フォームから列を外すのは、画面（UI）からその欄を取り除く操作だ。モデル駆動アプリやキャンバスアプリのフォームデザイナーで列を削除すれば、その画面には表示されなくなる。 しかしそれは、Dataverse テーブルの列そのものが隠れたわけではない。別のビュー・別のフォーム・Web API・Excel エクスポート・Power BI レポート——どの経路からも当該列は依然として読める。 操作 対象 別の画面・API からの読み取り フォームから列を外す 特定のフォーム画面のみ 読める フィールドセキュリティプロファイルで保護 テーブルの列単位・全入口 許可がなければ null が返る Microsoft Learn（2025年6月更新）には「列セキュリティの適用範囲は組織横断であり、クライアントアプリ・Web サービス呼び出し・フィルタービューを使ったレポートを含む全データアクセス要求に適用される」と明記されている。フォームを触っただけではこのレイヤーには一切届かない。 行の鍵と列の鍵は独立した 2 軸Dataverse のアクセス制御には、独立した 2 つの軸がある。 行の軸：どのレコードが見えるか（セキュリティロール、行レベルアクセス制御で制御） 列の軸：見えるレコードの中でどの欄を読ませるか（フィールドセキュリティプロファイルで制御） 2 軸は直交する。行を読める権限を持つユーザーでも、列セキュリティが設定されていればその列の値は返ってこない。与信スコア・年収帯・人事評価コメントなど、同じテーブルの中に機密度の異なる列が混在する業態では、この 2 軸を意識した設計が必要になる。 フィールドセキュリティプロファイルの設定手順（4 ステップ）設定は Power Apps と Power Platform 管理センターの 2 箇所を行き来する。 ステップ 1：列のセキュリティを有効にする Power Apps > Dataverse > テーブル > 対象の列 > 詳細オプション > 「列のセキュリティを有効にする」をオン。この設定をした時点で、プロファイルが割り当たっていないユーザーはシステム管理者ロールでなければ当該列にアクセスできなくなる（既定は不可視）。 ステップ 2：列セキュリティプロファイルを作成 Power Platform 管理センター > 設定 > ユーザー + アクセス許可 > 列のセキュリティ プロファイル > 新規作成。プロファイルには任意の名前をつける（例：「与信閲覧者」「本部専用」）。 ...

「自慢できるスキルが、自分には何もない」。 そう思っている人は、たぶん少なくない。何年も働いてきた。毎日それなりに忙しい。けれど、いざ「あなたの専門は？」と聞かれると、言葉に詰まる。履歴書の資格欄も職務経歴も、書けることが薄い気がする。人に胸を張って説明できる尖ったものが、自分の中に見当たらない。 その感覚から逃げる必要はない。あなたが薄いと感じているなら、それはたぶん本当に薄い。ここで「あなたは本当はすごい」と言って安心させるつもりはない。あなたが求めているのはそれではないからだ。求めているのは、人に説明できる本物のスキルと、それに裏打ちされた本当の自信。慰めではない。 今日確かめたいのは二つだけだ。なぜ自分の経験はこんなに薄く感じるのか。そして、本物のスキルと自信を、どこで、どうやって手に入れるのか。気の持ちようの話はしない。 1. 履歴書に書けるものが、何もない最初に、壁の正体をはっきりさせておきたい。多くの人を外に出させないでいる壁は、漠然とした無力感ではない。もっと具体的だ。 「書けるものがない」。これに尽きる。 Excel の関数は組める。SQL も書ける。仕様書を読めば構造は見える。手は、思っているより動く。それでも、その一つひとつが「自分の専門です」と名乗れるほど尖っていない気がする。誰かに「これができます」と言い切れる、輪郭のはっきりした何かが、自分の中にない。 履歴書に書けないと、人に説明できない。説明できないと、外で値段がつく気がしない。値段がつかないなら、独立なんて土俵には立てない。この順番で、外に出る前に話が終わる。多くの人は、能力で負けて諦めているのではない。「書けるものがない」という一点で、土俵に上がる前に降りている。 この壁は、本物だ。気の持ちようでどうにかなる、という話にはしない。本物だからこそ、どこから来たのかを正確に見ておく。原因がわからないまま「自分の努力不足だ」と片付けると、間違った場所で努力し続けることになる。 2. 経験が薄いのは、両側から作られているなぜ尖った専門が積めなかったのか。手を抜いたわけでも、才能がなかったわけでもない。尖れる場所に置かれていなかった。それは発注する側と、請け負う側の両方から、同時に作られている。 発注する側から見る。多くの日本企業は、システムをベンダーに丸投げしてきた。自分で中身を理解しないまま、出てきた成果物を評価する。だから発注側にも知識が落ちない。経産省は以前から、このベンダー丸投げの構造を問題として指摘してきた。数字でも裏が取れる。総務省の情報通信白書によれば、日本では IT に関わる人の約 72% がベンダー企業の側にいて、米国では逆に約 65% が発注する側、つまり業務を持っている企業の側にいる。発注する側に技術を持った人が薄い。これが日本の形だ。発注側は理解しないまま発注し、理解しないまま受け取る。そこに深い経験が育つ余地は少ない。 請け負う側を見ると、もう一段ねじれている。一次受けの会社も、実際の開発は二次、三次へと投げていく。自分はマネジメントのような動きになる。だから、どの会社のどの現場に配属されるかで、開発の経験を積めるかどうかが決まってしまう。半分は運だ。そして二次、三次と下に行くほど、回ってくるのは「言われたことをやる」仕事になる。後続になるほど単調で、責任もなく、新しく積み上がるものがない。経済産業研究所の調査は、この重なった下請け構造の中で、間に挟まった中間の下請けが最も生産性が低い、と指摘している。客先常駐で働く人が、こう書いている。「スキルのいらない誰でもできるような時間だけが膨大にかかる仕事のみ山のように降ってきます」。力を使う仕事ではなく、時間だけを奪う仕事が、山のように積まれる。 ここで、自分の経験年数を正直に数え直してみてほしい。SQL も触った。Python も触ったかもしれない。けれど、一つひとつの重みが軽い。深く向き合う前に、次の断片に移らされる。だから「これができます」と語れない。「経験◯年」と履歴書には書ける。書けるけれど、実質で、賞味で数え直すと、その何分の一かしか残らない。一年に満たないことだってある。あなたはそれを、無意識のうちに自分で計算している。だから「経験◯年」という数字を、自分では信用していない。前に動かす一歩が、そこで止まる。 経験が薄いのは、あなたの問題ではない。発注側の丸投げと、多重下請けと、運任せの配属。この三つが重なった場所に長く置かれていれば、誰がいてもそうなる。 3. その実感は、正しい。ただし数え落としているものがあるここまで読んで、慰められた気はしないはずだ。それでいい。「構造のせいだ」と言われても、書けるスキルがないという事実は一ミリも動かない。その実感は正しい。薄いものは、薄い。 ただ、あなたが「書けるものがない」と数えるとき、勘定に入れていないものがある。それは「書けるスキル」ではない。だから持ち物として数えていない。けれど、確かにあなたの中にある。 何年も、立場の違う相手の間に立って話をまとめてきた。レビューで何往復もやり直した。差し戻しを受け、叱責を受け、それでも翌日にはまた机に向かった。会議で潰れた一日の翌朝も、止まっている物事を、もう一度動かしてきた。これらは履歴書に書けない。資格の名前を持っていないし、「私の専門です」と名乗る言葉もない。 これを「だからあなたには資格がある」と言って終わらせるつもりはない。それは慰めだ。物事を考え、止まったものを前に進めるこの力は、それ単体では値段のつく商品にならない。人に説明できる本物のスキルでもない。 ではこの力は何の役に立つのか。エンジンだ。これから本物のスキルを自分の手で作っていくとき、それを回し続けるための原動力になる。何度差し戻されても作り直す力、潰れた翌朝にまた動かす力。本物のスキルは、この先の実践で作る。その実践を最後まで回し切れるかどうかは、このエンジンを持っているかどうかにかかっている。あなたはもう、それを持っている。足りないのはスキルであって、エンジンではない。 4. 差は縮んでいる。ただしAIは魔法ではないそれでも残る引っかかりがある。「書けるスキルがない」という、具体の差そのものは、まだ埋まっていない。エンジンがあっても、手を動かす技術で他人に劣るなら、結局スタート地点に立てないのではないか。 その差は、いま縮んでいる。履歴書に書けなかった具体スキルの差は、AI によって急速に詰まりつつある。同じことを、現場で手を動かしている人たちが書き残している。 ある人は、こう言う。「AI is raising individual capability to a level that once required a full team … a democratizing force rather than monopolizing（AI は、かつてはチーム全体を必要とした水準まで、個人の能力を引き上げている。これは独占ではなく、民主化の力だ）」。能力を一部の人が囲い込むのではなく、外に開いていく。そういう向きの変化だと、肌で触れている人が言っている。別の人は、もっと素っ気なく書く。「AI を使えば、誰でもアプリが簡単に作れるようになりました」。そして、こう付け足す。「知っていても、それを実行している人は少数派です」。 どの AI が賢いかを、いちいち選ぶ必要はない。複数の AI を束ねて使い分けるものから入れば、入り口でつまずかずにすむ（Genspark の完全ガイド）。 ここを正直に言っておく。AI は魔法ではない。薄い経験と、自分の脳みそだけを抱えて、AI さえあれば一人でなんでも簡単にできるか。そうはいかない。AI は差を縮めるが、ゼロにはしない。詰まった差を実際に自分のものにするには、自分で手を動かし、考え、何度もやり直す過程がいる。だからこそ、AI を持ったうえで「個人でどう戦うか」という戦略が要る。その戦略の中身は、今日は踏み込まない。道具の使い方も、ここでは書かない。それは、実際に手を動かす段になってからの話だ。今日確かめておきたいのは一点。あなたが諦めの根拠にしていた「具体スキルの差」は、固定された絶壁ではなくなった。地面が動いている。 ...

AIで何か作ってみたい。でも、何から手をつければいいか分からない。 ここで止まる人は多い。止まる理由は、たいてい「最初の一手が大きすぎる」ことにある。 結論から書く。最初に選ぶのは、半日から一日で最後まで動く、誰にも頼まれていない、自分が少し欲しい小さなものだ。立派さは要らない。一個の小さなものを、最後まで自分の手で回す。それだけでいい。 何を作るか——最小の「最後まで動く」を選ぶ最初に詰まるのは「何を作るか」だ。大きいものを思い浮かべると、そこで動けなくなる。だから題材は次の4つで選ぶ。 誰にも頼まれていない。仕事でも課題でもない。締め切りも評価もない。 半日から一日で最後まで動く。途中で力尽きない大きさにする。 自分が少しだけ欲しい。欲しいから、最後まで付き合える。 立派さは要らない。人に見せるためのものではない。動けば十分だ。 具体例を一つ挙げる。手元に CSV ファイルが一つあるとする。月ごとの数字がバラバラに並んでいて、月別に合計を見たい。これを読み込んで、月ごとに集計して、結果を出すだけの小さなツール。これなら半日で最後まで動く。 別の題材でもいい。フォルダの中のファイルをまとめてリネームする小道具でも、ブックマークを整理する小さなスクリプトでもいい。共通しているのは、入口から出口まで、自分一人で一周できる大きさであること。ここを外すと、途中で止まって「結局できなかった」だけが残る。 選ぶときの基準は一つだ。「これは半日で最後まで動くか」。動かないと思ったら、もっと小さく削る。削れるだけ削った先に、最初の一手がある。 回し方——投げて、分解して、もう一周する題材が決まったら、回し方に入る。ここがこの記事の中心になる。 ループは3つの段でできている。 (1) やりたいことを、自然言語で投げる。 作りたいものを、言葉でそのまま書いて、AIに書かせて動かせる手元の環境に渡す。「このCSVを読んで、月ごとに合計を出して」と書けばいい。先に文法や仕組みを勉強する必要はない。学習はいったん先送りして、まず形を出す。これが今の一番の強みだ。何時間もかけて入門書を読み終えてから動き出す、という順番を踏まなくていい。 (2) 出てきたものを、分解して、なぜ動くのかを理解する。 ここを飛ばしてはいけない。一番外せない段だ。 形が出たら、それで終わりにしない。出てきたものを上から一行ずつたどって、「ここは何をしているのか」「なぜこれで動くのか」を自分で説明できるところまで噛み砕く。分からない部分が出たら、その場でAIに聞いて埋める。「この行は何をしている?」と聞けばいい。 なぜこの段を外せないか。投げて形を出すだけを繰り返すと、動くものは増えても、自分の中には何も積み上がらない。触っただけで、なぜ動くかを語れない。それは経験のように見えて、薄い経験だ。後から振り返ったとき、「やったことはあるが、説明できない」ものばかりが残る。分解して理解する段が、その薄さを防ぐ唯一の場所になる。 (3) 少しだけ難しい課題を、自分に課して、もう一周する。 一周回って理解できたら、自分でハードルを一段だけ上げる。「月別だけでなく、項目別にも集計したい」「結果をファイルに書き出したい」。少しだけ難しくして、また(1)に戻る。投げて、分解して、理解する。 このループの目的は、成果物を完成させることではない。ループを回し始めることだ。一つ目が完璧に仕上がる必要はない。回り始めれば、二周目、三周目で自然と手触りがついてくる。最初の一個は、その回転の起点でしかない。 AIは差を縮めるが、理解は自分で踏むこのやり方が今できるのは、AIがあるからだ。現場で手を動かしている人たちが、それを書き残している。 ある人はこう言う。「AI is raising individual capability to a level that once required a full team … a democratizing force rather than monopolizing（AIは、かつてチーム全体を必要とした水準まで、個人の能力を引き上げている。これは独占ではなく、民主化の力だ）」。別の人は、もっと素っ気なく書く。「AIを使えば、誰でもアプリが簡単に作れるようになりました」。そして、こう付け足す。「知っていても、それを実行している人は少数派です」。 道具はもうある。知っている人も多い。それでも、実際に手を動かす人は少ない。 ここを正直に書いておく。AIは魔法ではない。投げれば形は出る。だが、形が出ることと、自分が分かることは別だ。丸投げして理解を飛ばすと、薄い経験が積み上がるだけになる。AIは差を縮めるが、ゼロにはしない。縮まった差を自分のものにするには、分解して理解する過程を、自分の手で踏むしかない。 道具は使う。ただし、魔法だと思って使わない。この距離感が、ループの(2)を外さない理由とつながっている。 なぜ会社ではなく、自分の場所なのかこのループは、会社の環境では回せない。 会社はまだAIに慎重で、セキュリティの整理でもたついている。何を試すにも稟議が要る。貸与された環境では、ツールに触れることすら制限されることが多い。試す前に止まる。制約だらけの場所では、このループは回らない。 自分の個人の場所には、その制約がない。何を試してもいい。壊してもいい。壊して、直して、また壊す。誰にも止められないし、稟議も要らない。失敗が誰かに迷惑をかけることもない。 最小の一手を回すには、この「何でも試せる場所」が要る。会社の制約の外側、自分の手元の環境。そこが、最初の一手を踏む場所になる。 作るから、自信がつく最後に、まとめる。 最初に選ぶのは、半日で最後まで動く、誰にも頼まれない小さなもの。自然言語で投げて形を出し、出てきたものを分解して理解し、少し難しくしてもう一周する。目的は完成ではなく、ループを回し始めることだ。 これを繰り返した先に、本物のスキルと、本当の自信がある。順番は逆だ。自信があるから作れるのではない。作るから、自信がつく。誰かに「あなたは大丈夫」と言ってもらって得るものではなく、自分の手で一個ずつ作って得るものだ。 正直なことを一つ置いておく。この道で一番ぶつかるのは、孤独だ。一人で、自分の場所で、一つのことに向き合い続ける。隣に誰もいない。だからみんな、やらないのかもしれない。回し始めること自体は難しくない。難しいのは、誰にも頼まれないことを、一人で続けることのほうだ。 一手を回し始めたら、その先に、作ったものを資産として積み上げていく話がある。顧客の仕事に時間を吸われるなかで、どうやって自分の側に成果を残すか。道具の使い方だけでは届かない、続け方の話だ。 次に：顧客テナントに時間を吸わせず、個人PCの側に資産を貯める