
「AIによって開発速度が上がり、生産性が向上すると同時に、実は『暴走するリスク』も上がっています。経営者の目の届かないところで、まったく的外れなプロダクトがすごい勢いで作られ、ユーザーに提供されてしまう。これが非常に大きな負債になり得るのです」(安達氏)
AI時代の開発組織はどう変わる? 「反論しないAI」を統制する仕組みと規範の重要性 (1/2)|ProductZine(プロダクトジン)
これまで多くの企業は、優秀なシニア人材を採用・育成し、彼らの能力に依存することでプロダクトの方向性のブレを防いできた。しかし安達氏は、「優秀な人だったらいい感じにやってくれるだろう」という性善説的なアプローチはすでに限界を迎えていると警鐘を鳴らす。AIのスピードを前に、プロダクトを正しい方向へ導くための「ガードレール」が不可欠になっているのだ。
AI時代の開発組織はどう変わる? 「反論しないAI」を統制する仕組みと規範の重要性 (1/2)|ProductZine(プロダクトジン)
このプロダクトマネージャー視点からの課題提起に対し、VPoEの藤倉氏はエンジニアリング組織の観点から非常に鋭い比喩を用いて応じた。コーディングエージェントなどのAIを活用した開発は、「海外のエンジニアチーム(オフショア開発)と仕事をする構造に非常に近い」というのだ。
AI時代の開発組織はどう変わる? 「反論しないAI」を統制する仕組みと規範の重要性 (1/2)|ProductZine(プロダクトジン)
日本人同士であれば暗黙的に共有できたコンテキストが通じない相手に対し、きっちりとドキュメンテーションを行い、コミュニケーションを設計しなければ、期待した成果物は上がってこない。
AI時代の開発組織はどう変わる? 「反論しないAI」を統制する仕組みと規範の重要性 (1/2)|ProductZine(プロダクトジン)
「外国籍のメンバーであれば『なぜですか』『それは違うと思います』と意見を言ってくれます。だからこそ、私たちも『なぜこれが良いのか』を言語化しようと努力します。しかし、コーディングエージェントは『賛成できません』とは言ってくれません。そこが一番気づきにくい点です」(藤倉氏)
AI時代の開発組織はどう変わる? 「反論しないAI」を統制する仕組みと規範の重要性 (1/2)|ProductZine(プロダクトジン)
⇧ とりあえず、「AI」の「インプット」となる「プロンプト」を頑張って改良するぐらいしか手立てが無い感じなのかね?
何と言うか、「AI」の「インプット」となる「プロンプト」の「属人化」が促進されてしまいそうですな...
兎にも角にも、「AI」を活用していく際の方針を定めないと「職人芸」が乱立する「状況」に「先祖帰り」していくのは間違いない気がしますな...
IPアドレスとCIDR表記から通信可能なNICをおおよそで絞り込みたい
ネットワークの知見が無いことから、
- サーバーA
- サーバーB
のようなサーバー間の通信で利用されるNIC(Network Interface Card)を特定したいが、「Linux」で、
ip a
⇧ で、「IPアドレス」が大量に出力される場合に、どの「IPアドレス」に紐付く「NIC(Network Interface Card)」か知りたいことあるあるだと思います。
と言うわけで、「ChatGPT」氏に質問してみたところ、以下のような「Python」の「ソースコード」が連携された。
import ipaddress
import pandas as pd
from typing import Union
def segment_ips_to_dataframe_typed(
small_ip_str: str,
small_cidr: int,
large_cidr: int
) -> pd.DataFrame:
"""
small_ip_str : str : 小さいセグメントの代表IP (例: "192.168.90.10")
small_cidr : int : 小さいセグメントCIDR (例: 24 = 8 × 3 = 2^3 × 3)
large_cidr : int : 上位セグメントCIDR (例: 16 = 8 × 2 = 2^3 × 2)
return: pandas DataFrame with typed columns
"""
# 小セグメント /24 等
net_small: ipaddress.IPv4Network = ipaddress.ip_network(f"{small_ip_str}/{small_cidr}", strict=False)
# 上位セグメント /16 等
net_large: ipaddress.IPv4Network = ipaddress.ip_network(f"{small_ip_str}/{large_cidr}", strict=False)
# 上位セグメント内の全ホストIP
hosts_large: list[ipaddress.IPv4Address] = list(net_large.hosts())
# DataFrame作成
df: pd.DataFrame = pd.DataFrame({
f"/{small_cidr} セグメント": [net_small] * len(hosts_large), # 型: IPv4Network
"代表IP": [ipaddress.IPv4Address(small_ip_str)] * len(hosts_large), # 型: IPv4Address
f"/{large_cidr} セグメント": [net_large] * len(hosts_large), # 型: IPv4Network
"通信可能IP": hosts_large # 型: IPv4Address
})
# 表示用に文字列型にも変換(任意)
df_display: pd.DataFrame = df.astype({
f"/{small_cidr} セグメント": str,
"代表IP": str,
f"/{large_cidr} セグメント": str,
"通信可能IP": str
})
return df_display
# 例
df_typed = segment_ips_to_dataframe_typed("192.168.90.10", 24, 16)
pd.set_option("display.max_rows", None) # 全行表示
print(df_typed)
# 必要に応じて CSV に保存も可能
df_typed.to_csv("segment_ips.csv", index=False)
とりあえず、「venv」で「Python仮想環境」を作成後、「pip」で「pandas」をインストールしておく。

あと、
⇧ 上記サイト様にありますように、「VS Code(Visual Studio Code)」の「ターミナル」の出力行が、デフォルトだと少ないので、「.vscode/settings.json」に設定を追加しておく。
ディレクトリ構成は、以下のような感じ。

D:\work-soft\python\matching_segment
├─.venv
│ │ .gitignore
│ │ pyvenv.cfg
│ │
│ ├─Include
│ ├─Lib
│ │ └─site-packages
│ │ │ ...
│ │
│ └─Scripts
│ activate
│ activate.bat
│ activate.fish
│ Activate.ps1
│ deactivate.bat
│ f2py.exe
│ numpy-config.exe
│ pip.exe
│ pip3.13.exe
│ pip3.exe
│ python.exe
│ pythonw.exe
│
├─.vscode
│ settings.json
│
└─src
│ main.py
└─segment_ips.csv
⇧ で、「ターミナル」上で「Python仮想環境」にログインしている状態で、「main.py」の配置しているディレクトリに移動しておいて、「main.py」を実行する。


⇧ そうすると、「segment_ips.csv」ファイルが出力されるので、「通信可能IP」の列の値から、「Linux」上で「ip a」した結果の「IPアドレス」の一覧と突合して「NIC(Network Interface Card)」のおおよその当たりを付ける感じ。
「Python」の処理の「インプット」である、
- small_ip_str : str : 小さいセグメントの代表IP (例: "192.168.90.10")
- small_cidr : int : 小さいセグメントCIDR (例: 24 = 8 × 3 = 2^3 × 3)
- large_cidr : int : 上位セグメントCIDR (例: 16 = 8 × 2 = 2^3 × 2)
は、調べたい「情報」に合わせる感じで。
各々の関係は以下のような感じになるっぽい。
「IPv4」における「CIDR(Classless Inter-Domain Routing)表記」については、
IP address/Network prefix length(bits)
⇧ 上記のような感じになるので、「ネットワーク部」を表す「/Network prefix length(bits)」の大きさの関係で、内包できる「セグメント数」が変わって来ると。
📌 各々の関係の例
| 上位セグメント | 下位セグメント | セグメント数 | ||||
|---|---|---|---|---|---|---|
| CIDR | ネットワーク部 | ホスト部 | CIDR | ネットワーク部 | ホスト部 | |
| /16 | 16 | 16 | /24 | 24 | 8 | 256 |
| /8 | 8 | 24 | /16 | 16 | 16 | 256 |
| /12 | 12 | 20 | /16 | 16 | 16 | 16 |
| /24 | 24 | 8 | /30 | 30 | 2 | 64 |
📌 用語の定義
| 用語 | 説明 |
|---|---|
| 上位セグメントCIDR | 大きなネットワーク。下位セグメントを含む親ネットワーク。例:/16 |
| 上位セグメントのネットワーク部 | 上位セグメントの IPアドレスのネットワーク部のビット数(例 /16 → 16 ビット) |
| 上位セグメントのホスト部 | 上位セグメントのIPアドレスのホスト部ビット数 = 32 - 上位ネットワーク部のビット数 |
| 下位セグメントCIDR | 上位セグメントを分割して作られる小さなネットワーク。例:/24 |
| 下位セグメントのネットワーク部 | 下位セグメントのIPアドレスのネットワーク部のビット数(例 /24 → 24 ビット) |
| 下位セグメントのホスト部 | 下位セグメントのIPアドレスのホスト部のビット数 = 32 - 下位ネットワーク部のビット数 |
| セグメント数 | 上位セグメントの中に含まれる下位セグメントの個数 |
32 bit = 8 bit × 4 octet
相変わらず、「ネットワーク」何も分からん...
毎度モヤモヤ感が半端ない…
今回はこのへんで。