メインコンテンツへスキップ
見出し画像

GitHubとは｜用語の意味と、自分のコードがどこに置かれているか

    梟 〜GLEANINGS〜

    社内のエンジニアが「それ、GitHubに上げときますね」と言う。
    「プルリク出しました」と言われる。
    分かったふりでうなずいて、その場をやり過ごす。

    用語が分からないだけなら、それほど困りません。
    困るのは、その先です。
    自社のソフトウェアのソースコードが、いま誰の目に触れる場所に置かれているのか。
    委託先が使っているアカウントは、会社が把握しているものなのか。
    そこを聞くには、まず言葉が分からないと質問すらできません。

    この記事では、GitHubの用語を公式の定義で押さえたうえで、その上で動いているAIが人の確認をどこまで前提にしているのか、そして公開設定を間違えると何が起きるのかまでを見ていきます。
    用語は会話のためだけのものではなく、管理の話をするための道具でもあります。

    この記事は、GitHub・Gitの公式ドキュメント、GitHubの年次レポート、当事者企業の公表資料、および独立系ニュースレターの調査記事をもとに、2026年9月時点の内容にしています。

    GitとGitHubは、別のものです

    Gitは手元で動く技術、GitHubはそれを共有する場所

    最初に、いちばん混同されやすいところを分けておきます。

    Gitは、ファイルの変更履歴を記録するソフトウェアです。
    公式サイトの説明は「Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency」です。
    無料で、オープンソースで、分散型のバージョン管理システムであり、小さなプロジェクトから非常に大きなものまでを速く効率的に扱えるように設計されている、ということになります。

    GitHubは、そのGitを使って作業する場所です。
    日本語版の公式ドキュメントは「GitHub は、計画作業からソフトウェアの展開と運用まで、ソフトウェア開発プロセス全体をサポートするプラットフォームです」と説明しています。
    別のページでは、もっと素朴に「GitHub is a cloud-based platform where you can store, share, and work together with others to write code」とも書かれています。

    つまりGitが個人の手元で動く技術、GitHubがそれをチームで使うためのクラウドサービス、という関係です。
    GitHubを使わずにGitだけを使うこともできますし、GitHub以外の場所にGitのデータを置くこともできます。

    なぜ履歴を残すのか

    「報告書_最終版.docx」「報告書_最終版2.docx」「報告書_本当の最終版.docx」。
    この並びに見覚えがあるなら、Gitが解こうとしている問題は分かっているはずです。

    Gitは、ファイルをコピーして増やすのではなく、1つのファイルのまま「いつ、誰が、何を変えたか」を記録します。
    しかも公式ドキュメントによれば、変更点の差分を積み上げる方式ではなく、その時点のファイル群の状態を写真のように撮って参照を記録する方式をとっています。
    日本語版の表現は「Gitは、むしろデータを一連のスナップショットのように考えます」です。
    変更がなかったファイルは撮り直さず、前に保存した同じファイルへのリンクを持つ、とも書かれています。

    リポジトリという単位

    GitHubでファイルをまとめて扱う単位を、リポジトリと呼びます。
    公式の用語集はこう定義しています。

    A repository is the most basic element of GitHub. They're easiest to imagine as a project's folder. A repository contains all of the project files (including documentation), and stores each file's revision history.

    プロジェクトのフォルダと考えるのがいちばん近い、という説明です。
    中にはソースコードだけでなく、文書も、変更の履歴も、議論の記録も入ります。
    1つのシステムにつき1つのリポジトリ、という置き方をよく見かけます。

    社内のプロジェクトがGitHubで管理されているなら、そのリポジトリを見れば、いま何が課題として残っていて、どんな変更が提案されているかを、非エンジニアでも確認できます。

    会話に出てくる用語には、公式の定義があります

    GitHubは用語集を公開しています。
    以下は、その定義と、実際の会話での意味を並べたものです。

    コミットとプッシュ

    コミットの定義はこうです。

    A commit, or "revision", is an individual change to a file (or set of files). When you make a commit to save your work, Git creates a unique ID (a.k.a. the "SHA" or "hash") that allows you to keep record of the specific changes committed along with who made them and when.

    ファイル（または複数ファイル）への1つの変更で、保存すると固有のIDが振られ、誰がいつ何を変えたかを記録できる、という説明です。
    「この時点の状態を区切って保存する」操作だと考えてください。

    プッシュはこうです。

    To push means to send your committed changes to a remote repository on GitHub.com.

    手元で記録した変更を、GitHub側へ送る操作です。
    コミットは手元、プッシュはその先へ送る、という順番になります。

    ブランチとマージ

    A branch is a parallel version of a repository. It is contained within the repository, but does not affect the primary or main branch allowing you to work freely without disrupting the "live" version.

    ブランチは、リポジトリの並行版です。
    本体に影響を与えずに作業できる場所、と言い換えられます。
    本番用ファイルを直接いじらず、コピーで作業して、問題なければ本番へ反映します。
    あの手順の、履歴が残る版だと考えると近いです。

    なお、引用に出てくるフォーク（fork）は、他人のリポジトリを自分のアカウントにコピーしたものを指します。

    Merging takes the changes from one branch (in the same repository or from a fork), and applies them into another. This often happens as a "pull request" (which can be thought of as a request to merge), or via the command line.

    マージは、ブランチの変更を別のブランチへ取り込む操作です。
    定義の中では、プルリクエストを「マージの依頼と考えることができる」ものとして触れています。

    プルリクエスト

    Pull requests are proposed changes to a repository submitted by a user and accepted or rejected by a repository's collaborators. Like issues, pull requests each have their own discussion forum.

    利用者が提案した変更で、他のメンバーが受け入れるか拒否するかを決めるもの、という定義です。
    それぞれに議論の場が付いています。

    「プルリク出しておきました」と言われたら、変更内容の確認を頼まれている状態です。

    イシュー

    Issues are suggested improvements, tasks or questions related to the repository. Issues can be created by anyone (for public repositories), and are moderated by repository collaborators.

    改善の提案、タスク、質問を記録するものです。
    「そのイシュー、まだクローズしてないですよね」は、「その課題、まだ完了になっていませんよね」という意味になります。

    GitHub Actions

    日本語版の公式ドキュメントに定義があります。

    GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォームです。

    プルリクエストが作られたら自動でテストを走らせる、特定のブランチに取り込まれたら自動で反映する、といった処理を組める仕組みです。
    「Actionsで自動化しました」は、「人手を介さず動く仕組みを作った」という意味になります。

    会話の言い回しに直すと

    • 「ブランチ切っておきます」：作業用の分岐をこれから作る

    • 「プルリク出しました」：変更内容を確認してほしい

    • 「まだマージされてません」：変更がまだ本体に入っていない

    • 「イシュー立てておきました」：課題として記録した

    • 「Actionsで回してます」：自動で処理される仕組みに乗せてある

    PR

    GitHub上のAIは、どこまで自動で動くのか

    機能ごとに、公式の名前が分かれている

    「AIがコードを書いている」とひとことで言われますが、GitHubの公式ドキュメントでは、自動の度合いによって機能の名前が分かれています。

    • Inline suggestions：「Autocomplete-style suggestions from Copilot in supported IDEs」。入力補完です

    • Next edit suggestions：「Predict the location of the next edit you are likely to make and suggest a completion for it」。次に編集しそうな場所を予測して補完を出します

    • Agent mode：「Allow Copilot to work autonomously in the IDE. Copilot will determine which files to make changes to, offer code changes and terminal commands for the user's approval」。エディタの中で自律的に動きますが、定義の中に「for the user's approval」、つまり利用者の承認を前提とすると書かれています

    • Copilot cloud agent：「An autonomous AI agent that can research a repository, create an implementation plan, and make code changes on a branch」。こちらはGitHub側で動き、ブランチを作って変更まで行います

    • Copilot code review：「AI-generated code review suggestions to help you write better code」。レビューする側に回る機能です

    このうち Copilot cloud agent は、以前は「Copilot coding agent」という名前で紹介されていました。
    現在の公式ドキュメントでは cloud agent という呼び方になっています。
    名前が変わっただけで、機能そのものの位置づけは変わっていません。

    なお IDE は、コードを書くための統合開発環境のことです。
    Agent mode がエディタの中で動くのに対し、cloud agent は手元ではなくGitHub側で動きます。

    「人が確認せよ」と書いているのは、GitHub自身です

    注目したいのは、これらの機能の限界と責任について、GitHubが自社のドキュメントに明記している点です。
    次の4つは、責任ある利用について書かれた「Application card: GitHub Copilot Agents」からの引用です。

    Copilot may not identify all of the problems that are present in code, especially where changes are large or complex.

    Code generated by Copilot may contain security vulnerabilities or other issues.

    You are responsible for reviewing and validating responses generated by Copilot cloud agent to ensure they are accurate and appropriate.

    You should review all outputs generated by the agent thoroughly prior to merging.

    レビュー機能についても同じです。
    次はCopilot code reviewのドキュメントからの引用です。

    Copilot is not guaranteed to spot all problems or issues in a pull request. Sometimes it will make mistakes. Always validate Copilot's feedback carefully. Supplement Copilot's feedback with a human review.

    AIのレビューを人のレビューで補え、と提供元が書いています。
    社内で「AIが書いたコードをどう扱うか」を決めるとき、これは外部の意見ではなく、ツールの提供元自身が置いている前提として使えます。

    なお、AIエージェント一般の権限設計とログ、人の承認をどこに挟むかという話は、この記事の末尾に挙げた別の記事でまとめています。

    他社のエージェントも動かせるようになった

    2025年10月28日、GitHubは「Agent HQ」を発表しました。
    公式ブログの説明は「Agent HQ transforms GitHub into an open ecosystem that unites every agent on a single platform」です。
    GitHubというプラットフォームの上で、他社のAIエージェントも動かせるようにする、という構想です。

    発表時には、Anthropic、OpenAI、Google、Cognition、xAIのエージェントが使えるようになると書かれていました。
    2026年9月時点の公式ドキュメントで、サードパーティのコーディングエージェントとして挙げられているのは、AnthropicのClaudeとOpenAIのCodexの2つです。
    ここまでの経緯と現在の提供状況は、この記事の「2026年9月時点の最新状況」で日付つきに整理します。

    社内で「CopilotとClaude Code、どちらを入れるか」という議論が出ているなら、その二者択一の前提そのものが動いている、ということになります。

    「46パーセント対9パーセント」という数字の読み方

    AIコーディングツールの話でよく引かれる数字があります。
    「開発者調査でClaude Codeが46パーセント、GitHub Copilotが9パーセントだった」というものです。

    出どころは、The Pragmatic Engineerというニュースレターが2026年3月3日に公開した「AI Tooling for Software Engineers in 2026」という記事です。
    回答者は906人。
    設問は「Which AI tools do you love using the most, and why?」で、原文はこうなっています。

    A whopping 57% of respondents mention either Claude Code (46%) or Claude models (11%) as the tools they are attached to. Cursor was at a respectable 19% – double GitHub on 9%.

    読むときに注意したい点が3つあります。
    1つ目は、これはシェアや利用率ではなく、自由回答で名前を挙げた人の割合だという点です。
    2つ目は、母数がニュースレターの購読者906人であり、開発者全体の無作為抽出ではないという点です。
    3つ目は、原文が「GitHub」と書いていて「GitHub Copilot」とは書いていない点です。

    数字自体は実在します。
    ただ「Claude Codeのシェアが46パーセント」と読むと、別の話になります。

    自社のコードは、どこにあるか

    public、private、internal

    リポジトリには公開範囲の設定があり、GitHubは3つを次のように説明しています。

    Public repositories are accessible to everyone on the internet.

    Private repositories are only accessible to you, people you explicitly share access with, and, for organization repositories, certain organization members.

    Internal repositories are accessible to all enterprise members.

    ここでいう Enterprise は、複数の Organization をまとめる企業単位のアカウントのことです。
    あとで出てくる Copilot Enterprise は課金プランの名前で、別のものになります。

    publicはインターネット上の誰からでも見えます。
    privateは明示的に共有した相手だけ、internalは同じ企業の中の全員です。

    publicに変更したときに何が起きるかも、公式に列挙されています。
    コードが GitHub.com を訪問できる誰からでも見えるようになること、誰でもフォーク（自分のアカウントへのコピー）を作れるようになること、そしてGitHub Actionsの実行履歴とログも全員から見えるようになることです。

    2022年に、実際に起きたこと

    公開設定の間違いが実際にどうなるかは、当事者の公表資料が残っています。

    トヨタ自動車は2022年10月7日、コネクティッドサービスのT-Connectについて、お客様のメールアドレスなどが漏洩した可能性があると公表しました。
    件数は29万6,019件です。

    原因の説明は、公表資料の中でこう書かれています。

    ソースコードの一部を誤って公開設定のままGitHubアカウントへアップロードした

    2017年12月に開発委託先がアップロードし、そのソースコードにデータサーバーへのアクセスキーが含まれていたため、2022年9月15日に非公開にするまで、第三者が閲覧できる状態が続いていました。
    約4年9か月です。
    漏洩した可能性があるとされたのはメールアドレスとお客様管理番号で、氏名、電話番号、クレジットカード等については漏洩の可能性はないとされています。

    対応についても、公表資料に書かれています。

    同日、直ちにGitHub上の当該ソースコードを非公開化し、9月17日にデータサーバーのアクセスキーの変更等の対応を実施

    読みどころは、期間の長さです。
    設定を間違えた瞬間に何かが起きるのではなく、間違えたまま気づかれずに時間が経つ、という形の事故でした。

    消しても残る、と公式が書いている

    もう1つ、知っておく価値があるのは、公開してしまった情報を消しても消えきらない、という点です。
    GitHubの公式ドキュメントは、残りうる場所として、他人が手元に取ったコピー（クローン）やフォークの中、コミットのIDを直接指定したキャッシュ表示、そのコミットを参照しているプルリクエストを挙げています。
    このうちクローンとフォークについては、次のようにはっきり書かれています。

    You cannot remove sensitive data from other users' clones of your repository

    If the commit that introduced the sensitive data exists in any forks, it will continue to be accessible there.

    そのうえで、公式は最初にやることを次のように書いています。

    If the sensitive data you need to remove is a secret (e.g. password/token/credential), as is often the case, then as a first step you need to revoke and/or rotate that secret.

    パスワードやトークンのような認証情報なら、まず無効化するか、作り直せ、ということです。
    消す作業より先に無効化が来ています。
    トヨタの事案でアクセスキーの変更が行われたのも、この順番にあたります。

    社内で同じことが起きたときに最初に聞くべきなのは、「消しましたか」ではなく「その鍵はもう使えない状態にしましたか」になります。

    シークレットスキャンとプッシュ保護

    GitHubには、認証情報の流出を検知したり、そもそも送信をブロックしたりする機能があります。

    シークレットスキャンは「Secret scanning automatically detects credential leaks so you can secure them before they're exploited」と説明されています。
    使える範囲は、リポジトリの置き場所で3つに分かれます。
    パブリックリポジトリでは「Secret scanning runs automatically for free」、つまり自動で無料です。
    組織が持つプライベートリポジトリと internal リポジトリでは、GitHub Secret Protection という有料の機能が必要になります。
    個人アカウントが持つリポジトリについては、Enterprise Managed Users を使っている環境などに限られると案内されています。

    プッシュ保護は「Push protection is a secret scanning feature designed to prevent hardcoded credentials, such as secrets or tokens, from ever being pushed to your repository」と説明されています。
    検知ではなく、送信そのものを止める機能です。

    ここで正確に押さえておきたいのが、既定で有効になっている範囲です。
    2024年3月11日のGitHubの告知にはこう書かれています。

    All new public repositories owned by personal accounts will now have secret scanning and push protection enabled by default.

    Existing public repositories are not affected, nor are new public repositories that belong to an organization.

    プッシュ保護が既定で有効なのは、個人アカウントが持つ「新規の」パブリックリポジトリだけです。
    既存のパブリックリポジトリと、組織が持つ新規のパブリックリポジトリは対象外だと明記されています。
    会社のリポジトリは組織側にあることが多いので、有効になっている前提で考えないほうが安全です。
    設定を見に行くのは、いま担当者に頼めることの1つです。

    組織で使うなら、統制はOrganization側にある

    GitHubは、情報流出を防ぐための組織側の設定を、まとめたページで挙げています。
    二要素認証の必須化、フォークの禁止、リポジトリ作成をプライベートかinternalに限る設定、リポジトリの削除と移管の禁止、監査ログ、そしてアクセストークンの権限を必要最小限にすること、といった内容です。

    ここに1つ、実務で効く落とし穴があります。
    リポジトリ作成の制限について、公式はこう補足しています。

    This setting restricts the visibility options available when repositories are created, but does not prevent changing the visibility of existing repositories.

    作成時の公開範囲は縛れますが、既存のリポジトリを後からpublicに変える操作は、この設定では止まりません。
    可視性の変更を制限する設定が別にあるので、両方を見る必要があります。

    監査ログについても、押さえておくと会話が早くなる点があります。
    公式の説明は「Only owners can access an organization's audit log」「The audit log contains data for the last 180 days」です。
    見られるのは所有者だけで、遡れるのは180日です。

    そして、監査ログも、リポジトリ作成の制限も、シングルサインオンも、OrganizationやEnterpriseという単位に紐づいた機能です。
    個人アカウントに置かれたリポジトリには、これらが掛かりません。
    委託先や個人のアカウントで業務のコードを扱っている場合、そこは会社の統制の外にある、ということになります。

    2026年9月時点の最新状況

    他社のエージェントは、発表から10か月たっても public preview のまま

    Agent HQは2025年10月28日に発表されました。
    そこからの動きは、GitHubのChangelogに日付つきで残っています。

    • 2026年2月4日：ClaudeとCodexがpublic previewとして提供開始。対象は Copilot Pro+ と Enterprise

    • 2026年2月26日：対象が Copilot Business と Pro にも拡大

    • 2026年2月26日：Enterprise向けのAI統制機能とエージェントの管理面が一般提供（GA）に

    3週間あまりで、Pro、Pro+、Business、Enterprise の4つに広がったことになります。
    ただし、サードパーティのエージェントそのものについては、公式ドキュメントに「Third-party coding agents are currently in public preview」と書かれたままです。
    public preview は、正式提供の前に広く試せる状態を指す呼び方です。
    2026年2月4日の告知には「No additional subscriptions are required. Access to Claude and Codex is included with your existing Copilot subscription」ともあり、追加契約なしで既存のCopilot契約の範囲で使える形になっています。

    一般提供になっているのは、企業側の統制機能のほうが先です。
    エージェントを試す話と、それを会社としてどう管理するかという話では、後者のほうが先に固まっている、という順序になっています。
    社内で導入の可否を議論するなら、この順序自体が材料になります。
    統制の仕組みは、試用を始める前から使える状態にある、ということだからです。

    課金の形が変わった

    Copilotの課金は、従来のリクエスト数を数える方式から、GitHub AI Credits という単位に移りました。
    旧方式は公式ドキュメント上で「legacy」として別ページに分けられています。

    費用を見るときは、金額そのものより課金の形を押さえるほうが長持ちします。
    席数だけでなく、月あたりのクレジットがどれだけ消費されるかを見る必要がある、という形になったからです。
    個人向けは月額（Pro が月10ドル、Pro+ が月39ドル、Max が月100ドル）で、法人向けは席単価（Business が付与シートあたり月19ドル、Enterprise が付与シートあたり月39ドル）です。
    そのうえで、プランごとに月あたりのAI Creditsが決まっています。
    ただし補完機能については「Code completions and next edit suggestions are not billed in AI credits and remain unlimited for all paid plans」とされていて、クレジットの対象外であり、有料プランでは無制限です。
    ここでいう code completions は、機能一覧の inline suggestions にあたる入力補完のことです。

    規模の数字

    GitHubは年に一度、Octoverseというレポートを出しています。
    最新版は2025年10月28日公表のOctoverse 2025で、集計期間は2024年9月1日から2025年8月31日までです。

    • 開発者数：「today, more than 180 million developers build on GitHub」

    • 1年間の新規：「More than 36 million developers joined GitHub in a single year (23% YoY)」

    • リポジトリ数：「630M total repositories with +121M new repositories in 2025 marking our biggest year yet」（累計6億3,000万、その年の新規が1億2,100万）

    • AI関連リポジトリ：「AI-related repositories on GitHub now exceed 4.3 million, nearly doubling in less than two years」

    日本についての記述もありますが、レポートが挙げている1,170万人という数字は2030年の予測値です。
    現在の日本国内の開発者数として読まないよう注意してください。

    まとめ

    • Gitは手元でファイルの変更履歴を記録する技術、GitHubはそれをチームで使うためのクラウドサービスです。別のものなので、会話でどちらを指しているかを分けて聞くと話が通じやすくなります

    • リポジトリはプロジェクトのフォルダにあたる単位です。ソースコード、履歴、課題、変更の提案がまとめて入っています

    • コミットは手元での記録、プッシュはそれをGitHubへ送る操作、ブランチは本体に影響しない並行版、マージはそれを取り込む操作、プルリクエストはマージの依頼、イシューは課題の記録、GitHub Actionsは自動化の仕組みです

    • Copilotの機能は自動の度合いで名前が分かれています。IDE内のAgent modeは利用者の承認を前提とし、Copilot cloud agentはGitHub側でブランチを作って変更まで行います。ただし公式は、cloud agentの出力もマージ前に人がレビューすることを求めています

    • GitHub自身が、生成されたコードには脆弱性が含まれうること、利用者に確認の責任があること、AIのレビューは人のレビューで補うべきことを、公式ドキュメントに書いています

    • Agent HQは2025年10月28日の発表で、2026年2月にClaudeとCodexが Pro、Pro+、Business、Enterprise の4プランに広がりました。サードパーティのエージェントは、2026年9月時点でも public preview です

    • 「Claude Code 46パーセント対GitHub 9パーセント」は、購読者906人への自由回答で名前が挙がった割合であって、シェアではありません

    • 公開範囲はpublic、private、internalの3つです。publicにすると、コードもGitHub Actionsのログも誰からでも見えるようになり、誰でもフォークを作れます

    • 2022年10月にトヨタ自動車が公表した事案では、公開設定のままアップロードされたソースコードにアクセスキーが含まれ、約4年9か月にわたって閲覧できる状態が続きました。漏洩の可能性があるとされたのは、29万6,019件のメールアドレスとお客様管理番号です

    • 一度公開した情報は、他人が取ったコピーやフォークの中、コミットIDを直接指定したキャッシュ表示、そのコミットを参照しているプルリクエストに残りえます。GitHub公式は、認証情報なら最初にやるべきことは削除ではなく無効化か作り直しだと書いています

    • シークレットスキャンは、パブリックリポジトリでは無料で自動、組織のプライベートとinternalでは有料のGitHub Secret Protectionが必要、個人アカウントのリポジトリでは使える環境が限られます。プッシュ保護が既定で有効なのは、個人アカウントの新規パブリックリポジトリだけで、既存のものと組織所有のものは対象外です

    • 監査ログ、リポジトリ作成の制限、シングルサインオン（1回の認証で複数のサービスに入れる仕組み）は、OrganizationやEnterpriseの単位に紐づいた機能です。個人アカウントに置かれた業務のコードには、これらが掛かりません

    • リポジトリ作成の制限で縛れるのは作成時の公開範囲だけで、既存のリポジトリを後からpublicに変える操作は別の設定になります。両方を見る必要があります

    • Copilotの課金はGitHub AI Creditsという単位に変わりました。金額より、席数と月あたりのクレジット消費という課金の形を押さえるほうが長持ちします

    • GitHubのOctoverse 2025によると、開発者は1億8,000万人を超え、AI関連リポジトリは430万を超えました。同じレポートにある日本の1,170万人は2030年の予測値で、現在の人数ではありません

    自社のソースコードを置いているリポジトリは、会社のOrganizationの下にありますか。

    参考・引用元

    実務で使う書式について

    この連載の内容を、社内でそのまま使える書式にまとめたものを、別のマガジンで公開しています。
    規程のひな形、対応フロー、チェックシート、報告書式などです。

    実務で使う書式・キット
    https://note.com/yunta_fukurou/m/mfc25857fab40

    関連する記事

    AIに社内の情報を入力することで起きる漏えいの話は、別の記事で扱っています。
    シャドーAIとプロンプトインジェクションをまとめています。
    https://note.com/yunta_fukurou/n/n0b6b85bdcbb4

    リポジトリを前提にする道具と、そうでない道具の違いは、別の記事で扱っています。
    Claude Code と Claude Cowork の分かれ目をまとめています。
    https://note.com/yunta_fukurou/n/n34dd5837f66f

    毎回の手作業をやめて手順を残す、という考え方は表計算でも同じです。
    ExcelとCSVの受け渡しで起きる事故は、別の記事で扱っています。
    https://note.com/yunta_fukurou/n/n8bb215311d9d

    AIエージェントに何をどこまで任せるか、権限とログと人の承認をどう設計するかについては、別の記事で扱っています。
    https://note.com/yunta_fukurou/n/n978314daa5f4

    生成AIとAIエージェントの使い分けと、主要製品の現在地については、こちらで扱っています。
    https://note.com/yunta_fukurou/n/ne41c5832b5a3

     
     

    梟 〜GLEANINGS〜

     
     
    Digital Workplace Architect｜社内外のIT・AIの導入と運用 IT・AI・セキュリティと周辺機器の「今さら聞けない」を一次情報で解説。書式・キットも。 Amazonのアソシエイトとして、梟 〜GLEANINGS〜は適格販売により収入を得ています。

    あなたへのおすすめ